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Terminate Rental 

1. Terminate Rental Use Case 

1.1 Brief Description 

The Terminate Rental use case describes how the USER would terminate a rental. This use case will allow 
the USER to inform Enterprise of the last day that the ADJUSTER will pay for a rental. In most cases, by 
providing a date in the future, Enterprise will receive an extension through the last day. 

1.2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The USER will use this case to terminate a rental. 

1.3 Pre-Conditions 

• The USER must be logged into the ARMS Web system. 

• The USER must have the authority to terminate an open rental. 

• The USER must have selected an authorized rental. 

1.4 Flow of Events 

The Flow of Events will include the necessary steps to terminate a rental. 




1.4.2 Basic Flow 

1 . The USER selects to terminate an authorization. 

2. The system prompts the USER for the termination information. 

3. The USER enters the termination date and reason/comments. 

4. The USER submits the termination information. 

5. The system will validate the termination information. 

6. The system updates the ARMS Web database. 

7. The system reads the USER profile for the confirmation settings. 

8. This ends the use case. 

14.3 Alternative Flows 

1.4.3.1 Previous 

After step 3, the USER can abandon all changes, which result in the system state remaining 
unchanged. After clicking the "Previous" button, the USER will be returned to the screen from 
which they came. 

1.4.3.2 Additional Comments 

When terminating a rental, the USER must select a reason from the drop-down box to explain 
why the termination is taking place. As well, if further explanation is desired there is a comment 
box in which the USER may enter additional comments for more clarification. This section is 
optional, unless the USER selects "Other" from the reason code drop-down box. In this case, the 
comment box must be used. 

1.4.3.3 Display Confirmation 

After step 7, the USER may wish to have a confirmation page displayed, indicating that some type 
of change has taken place. The confirmation page is completely optional; therefore, at anytime 
the USER wants to set their profile to bypass this screen, he/she may do so. 

1.4.3.4 Update USER Profile 

During the confirmation process, the USER has the option of changing their profile setting to 
display or hide the confirmation page. Each time the setting is changed, the USER profile must be 
updated to reflect the new requirements set by the USER. 

1.5 Post-Conditions 

• If the use case was successful then the changes will go into effect immediately and write a 
transaction record to pass to ARMS indicating that there was a change on the rental. If the renter's 
email address was entered, a system-generated message will notify the renter. 

• If the use case was unsuccessful then the system will remain unchanged. 





1.6 Special Requirements 



1.6.1 The termination date must be greater than or equal to the current date or the last day authorized. 
There is a business rule that ensures that an adjuster cannot take away already used rental days. 

Current Date Authorization Date Termination Date 

6/20 6/25 >=6/20 

6/20 6/10 >=6/10 

1.6.2 If the USER extends an authorization that has been terminated, the termination information is 
considered invalid. 

1 .6.3 It is mandatory that a USER select a termination reason from the drop-down list. If the USER 
selects "Other" from the drop-down list, a comment about the termination must be supplied. 



1.7 Extension Points 

None. 



Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be-used to implement support for the use case flow. 



2.1 Terminate Re ntal _ 



nay be-used 

,3f) 



This screenj^Uallow the user enter the information about terminating a rental. 
2.1.1 Screen Layout - Terminate Rental — S€eJvT GijV-C t~ > 3> \ 



., ^ ^ Set Last Day of Rental 

nter: Weber, Andrew 

?'tr,in?ti:n Date. QBHE] MFl HnSTiF*f ii : 



Please notify renter 



2.1.2 Terminate Rental 















Comment: 


Input 


50 


Message Text 


NOTE 


Required field if Reason selected is 
"Other" 


Reason: 


List Box 


30 


Reason 


NOTE 


Required Field 


Termination 
Date 


List Box 


10 


Termination Date 


Termination Date 


The date entered must be the current date 
or later. This is the date that the 
insurance company will no longer pay 
for the rental. / This field should have a 
calendar control associated with it to 
allow the user to select the date of loss 
from a calend 




Output 


30 


Renter's Name 


First Name + Last 


Renter's Last Name + Renter's First 



2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Previous 

Will return the user to the detail screen from which they came. The system and the 
information on the detail screen will remain unchanged 

2.1.3.2 Process 

When clicked, the system will complete the termination of the rental and notify the 
required parties. 



2.1.3.2.1 The user must have selected a valid termination date that is greater than the current date 




3. Application Operations 
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4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Company Id 


Entity 


ARM: ARMS/400 Internal Error Log File 


Column Name 


E4CUID 


Label Name 


Company Id 


System Name 




Data Type 


CHAR(5) 


Attribute Definition 




4.1.2 external organization abbreviated name 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(IO) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 


4. 1.3 external organization identifier 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The external organization identifier is a surrogate key assigned to each 
unique occurrence of an External Organization. Examples: body shops, 
vehicle manufacturers, insurance companies, leasing accounts, credit unions, 
dealerships, or government agencie 


4.1.4 First Name 


Entity 


ARM: Adjuster Master 


Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.15 First Name 


Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 






Data Type 


CHAR(15) 


Attribute Definition 




4.16 Insurance Claim Number 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR{20) 


Attribute Definition 




•4.17 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.18 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.19 NOTE 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 




4.1.10 renter email 


Entity 


RENTER EXTENSION 


Column Name 


rentr eml 


Label Name 


renter email: 


System Name 


RENTREML 


Data Type 


CHAR(70) 


Attribute Definition 


The email address of the renter. 


4.1.11 Termination Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZTMDT 


Label Name 


Termination Date 




System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





5. Questions and Answers 



Issue Number: 373 



Question: How is the renter currently notified of a termination of the rental? Are they usually 
notified by the time the rental is terminated? How should this be represented on the screen? 
Should the checkbox say to notify the renter or that the renter has already been notified? 



Status: Pending 



Resolution: 
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14.2 Basic Flow 



1 . The USER selects to reassign a customer file. 

2. The system retrieves the list of valid offices to display. 

3. The system retrieves the list of valid USERs to display based on reservation/ticket status. 

4. The system displays the list of adjusters for the current office and the list of other valid offices. 

5 . The USER selects the user that will be the new owner of the selected action item. 

6. The system will update he ARMS Web database to reflect the recent ownership change and 
changes, if any, from the prior screen. 

7. The system generates a message indicating that a transfer and any other changes have been 
completed. 

8. The system updates the ARMS Web database and notifies ARMS with an Authorization Change 
transaction. 

9. This ends the use case. 



1.4.3 Alternative Flows 

1.4.3.1 Change Office 

After step 3 of the basic flow, the USER may choose to assign the action item to a new office. If 
the USER chooses a new office, the flow would return to step 2 of the basic flow. This should 
reflect possible recipients of the action item from that office. 



1.4.3.2 Cancel Use Case 

The USER may cancel the use case at any point prior to updating the ARMS Web Database. If 
the USER elects to cancel the use case, the customer file will not be transferred, however, any 
other changes that were made to the file will remain. 



1.4.3.3 Display Confirmation 

After step 7, the USER may wish to have a confirmation page displayed, indicating that some type 
of change has taken place. The confirmation page is completely optional, therefore, at anytime 
the USER wants to set their profile to bypass this screen, he/she may do so. 

1.4.3.4 Update USER Profile 

During the confirmation process, the USER has the option of changing their profile setting to 
display or hide the confirmation page. Each time the setting is changed, the USER profile must be 
updated to reflect the new requirements set by the USER. 

Post-Conditions 

• If the use case was successful then the changes should go in to effect immediately and the new owner 
should be able to view the newly assigned action item. 

• If the use case was unsuccessful then the system will remain unchanged. 
Special Requirements 

• When building the list of valid USERS, the system will determine the status of the reservation / ticket 
and retrieve all users in the current office with authority to process that status of a reservation / ticket. 

• When building the list of valid Offices, the system will retrieve all other offices defined within ARMS 
Web as valid offices for the specified company. 

• When selecting an office for the reassign operation, the system must rebuild the user list so the USER 
will only see valid users that are able to complete the action item to be transferred. 

• After the changes have been submitted, the next Action Item will populate indicating that a transfer 
has been completed, if the USER started from the Action Item List 



Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to 
implement the flows identified above. More than one screen may be used to implement support 
for the use case flow. s. 

Transfer FHe^ O^S^ ^ 

This screer/will allow the user to pick which functions that they may want to change. 
2.1.1 Screen Layout - Trans fer File -^j?-^ ^\ b ^ 



Transfer File 

Any changes made to this file will be transferred when you process. 

Adjuster currently handling this customer file: 

Claims Office: 001 
Adjuster's Name: Fitzaera 3. i .si: 

Select the adjuster you want to transfer this customer file to: 

Claims Office: EBHTj 
Adjuster's Name: l»MI=Wfgi^r| 



2.1.2 Transfer File 













Adjuster's Name 


ListBox 


30 


Change to Adjuster's 


First Name + Last 


List of adjuster's within the currently 
selected Assign to Claim Office that are 
authorized to handle the current request 
type. The adjuster that the request is 
currently assigned to will be selected 
upon entry into the screen. 


Adjuster's 


Output 


30 


Current Adjuster's 
Name 


First Name + Last 


N/A. 


Claims Office 


ListBox 


3 


Change to Office Id 


external organization 
identifier 


List of office within the current Company 
Structure that are authorized to handle 
the current request type. The office that 
the request is currently assigned to will 
be selected in the drop down box upon 
entry into the screen. 


Claims Office: 


Output 


3 


Current Office Id 


external organization 
abbreviated name 


N/A 




2.1.3 Screen Function Definition 

2.1.3.1 Cancel 

When clicked, the USER will be returned to the screen/use case where they 
were prior to selecting Change Office/ Adjuster (Transfer). Any changes made 
will be lost and the system will remain unchanged. 

2.1.3.2 Process 

When clicked, the changes made will be validated. If the validation passes, the 
update will be sent to the ARMS system and the USER will be returned to the 
screen/use case from which they came. If the validation fails, the USER will be 
returned to the current screen with error message(s) and the field in error 
highlighted 




4. 

4.1 



Data Fields 



Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4. 1. 1 external organization abbreviated name 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(IO) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 


4.1.2 external organization identifier 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier: 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The external organization identifier is a surrogate key assigned to each 
unique occurrence of an External Organization. Examples: body shops, 
vehicle manufacturers, insurance companies, leasing accounts, credit unions, 
dealerships, or government agencie 


4.1.3 First Name 


Entity 


ARM: Adjuster Master 


Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.4 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 
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Cancel Authorization 

1. Cancel Authorization Use Case 

1.1 Brief Description 

This use case will describe how a USER would cancel an authorized reservation. 

1.2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The USER will be able to perform the duties of canceling an authorized reservation. 

1.3 Pre-Conditions 

• The USER must be logged into the ARMS Web system. 

• The USER must have the ability to cancel an authorization. 

• The USER has selected an authorized reservation and wants to cancel the authorization within ARMS 
Web. 

1.4 Flow of Events 

The Flow of Events will include the necessary steps to "Cancel Authorization". 



Basic Flow 



1 . The USER selects to cancel the authorization. 

2. The system will prompt the user for a reason for cancellation. 

3 . The USER will select a reason. 

4. The USER will submit the cancellation. 

5. The system will update the ARMS Web database to reflect that the USER cancelled the Authorization. 

6. The system will read the USER profile for the confirmation settings. 

7. This ends the use case. 

Alternative Flows 

1.4.3.1 Previous 

After step 3, the USER can abandon all changes, which result in the system state remaining unchanged. 
After clicking the "Previous" button, the USER will be returned to the screen from which they came. 

1.4.3.2 Additional Comments 

When canceling a rental, the USER must select a reason from the drop-down box to explain why the 
cancellation is taking place. As well, if further explanation is desired, there is a comment box in which 
the USER may enter additional comments for more clarification. This section is optional, unless the 
USER selects "Other" from the reason code drop-down box. In this case, the comment box must be used. 

1.4.3.3 Display Confirmation 

After step 6, the USER may wish to have a confirmation page displayed, indicating that some type of 
change has taken place. The confirmation page is completely optional, therefore, at anytime the USER 
wants to set their profile to bypass this screen, he/she may do so. 

1.4.3.4 Update USER Profile 

During the confirmation process, the USER has the option of changing their profile setting to display or 
hide the confirmation page. Each time the setting is changed, the USER profile must be updated to reflect 
the new requirements set by the USER. 

Post-Conditions 

• If the use case was successful then the changes should go in to effect immediately and generate a 
transaction record to pass to ARMS indicating that the authorized reservation was cancelled. 

• If the use case was unsuccessful then the system will remain unchanged. 

Special Requirements 

• When canceling an authorization, the USER must select a reason from the drop-down list If the 
USER chooses "Other" from the pre-defined list, a comment about why the authorization was 
cancelled must be supplied. 

Extension Points 

None 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

2.1 Cancel Direct^illAiithorJza^ flj,^t3 ^ j 

This screen ^Hallow the user to pick which functions that he/she may want to change. 

2.1.1 Screen Layout -Cancel Direct Bill Authorization — Sr\j */f <- & N 



Sv ^— . — Cance! item 
Cancel Direct Bill Authorization 

You have chosen to cancel the following item. 
Renter's Name Claim # 

Weber, Andrew 364829484082223542 



Mar*- 



2.1.2 Cancel Direct Bill Authorization 

















List Box 


50 


Cancellation Reason 


NOTE 


N/A 


Comment: 




50 


Message Text 


NOTE 


Required if cancellation reason is 
"Other" 


Claim # 


Output 


30 


Claim Number 


Insurance Claim 
Number 




Renter's Name 


Output 


30 


Renter's Name 


First Name + Last 


N/A 




2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. This 
includes operations invoked by button clicks, specific shortcut keystrokes, or other actor activity. 



2.1.3.1 Previous 

When clicked, the user will be returned to the screen/use case where they were prior to selecting 
Cancel Reservation. Any changes made will be lost and the system will remain unchanged. 

2.1.3.2 Process 

When clicked, system will update the message file with the comment record if entered and mark 
the current reservation authorization as cancel. The cancellation and the new message, if entered, 
will be forwarded to the ARMS system. The system returns the USER to the appropriate Action 
Items List screen. 





4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Cancel Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCNDT 


Label Name 


Cancel Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.2 Cancellation Code 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCNCD 


Label Name 


Cancellation Code 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.3 external organization abbreviated name 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(10) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 


4.1.4 First Name 




Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.5 Insurance Claim Number 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 






> 




4.1.6 Last Name 



Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.7 NOTE 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 




4.1.8 Rental Location 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZRNLC 


Label Name 


Rental Location 


System Name 




Data Type 


CHAR(10) 


Attribute Definition 






^Isaiepate^OGO^ 



Ssuicej Authorization^ 

5 . Questions and Answers 



Issue Number: 418 



Question: Do we need a reas< 
Status: Closed -Resolved 



n to cancel - have cancel page. 



Resolution: 6-23-00,Per Neil, kill this page, 



it's not necessary. 
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2.3 Search Results 

2.3.1 Screen Layout - Search Results 

2.3.2 Search Results 

2.3.3 Screen Function Definition 

3. Application Operations 

4. Data Fields 
4. 1 Data Field Definition 




4.1.1 


Add Date 


4.1.2 


Address Line 


4.1.3 


Address Line 


4.1.4 


Address Line2 


4.1.5 


Bill To % 


4.1.6 


Bill to End Date 


4.1.7 


Bill to Start Date 


4.1.8 


Branch 


4.1.9 


City 


4.1.10 


City 


4.1.11 


City 


4.1.12 


claim type code / 


4.1.13 


claim type description 


4.1.14 


company identifier/ 


4.1.15 


Date Of Loss / 


4.1.16 


Day Phone / 


4.1.17 


Days authorized-detail 
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State 
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1 . Search and View Customer File 

1 .1 Brief Description 

This use case describes the process that a USER would use to find and view information regarding a rental. 
In order to view the rental detail, one of two general conditions must be satisfied: 

1) The rental is open and the USER does not have any authority to make changes 

2) The rental is in a state that no longer allows changes to be made. 

If these conditions are not met, the USER will be taken to the appropriate use case. 

1.2 Use Case Actors 

All actors will use the use case to View Rental Detail in the ARMS Web system. All of the following 
actors can be defined generically as a USER: 

• ADJUSTER 

• PROCESSOR 

• COMPANY MANAGER 

• ENTERPRISE ADMINISTRATOR 

• COMPANY ADMINISTRATOR 

1.3 Pre-Conditions 

• The USER must be signed-on to the system 
(AND) 

• The USER does not have the authority to make changes and the ticket is open, 
(OR) 

• The ticket is in a state that doesn't allow changes to be made. 

1.4 Flow of Events 

The Flow of Events includes all the steps necessary to View Rental Detail in the ARMS Web system. 



The Basic Flow of the View Rental Detail use case includes all of the required activities for the USER to 
successfully find and view information regarding an open rental. 

1 . The USER initiates a search for a Customer File. 

2. The system, based on criteria entered by the USER, retrieves the matches for that search. 

3. The system displays the search results. 

4. The USER selects one of the matches. 

5. The system displays the detail of the Customer File. 

6. This ends this use case. 



1.4.3 Alternative Flows 

1.4.3.1 Search Again 

After step 3 of the basic flow, the USER may decide that they would like to conduct another 
search. By entering new search criteria, they would return to step 2 with new criteria and the u 
case could continue. 



1.4.3.2 Only One Match Found 

At step 2 of the basic flow, if the system only finds one match, the system will advance to step 5 
of the basic flow invoking the appropriate use case for modifications. 

1.4.3.3 View Only 

If the Customer File selected was in a state not allowing changes, the system would display the 
Customer File, however, not allowing the USER to modify any information within ARMS Web. 



• If the use case is successful, the system will return to its previous state. 

• If the use case is unsuccessful, the use case the system will remain unchanged. 
1.6 Special Requirements 

To successfully locate a customer file, the following criteria must be satisfied: 

l . The following fields will limit the search results: Adjuster Name, Last Authorized Day, Date of 
Loss, and/or a status of the Customer File. 

a. If a Renter Last Name has been supplied, an exact match on last name is considered valid 

b. If a Renter Last Name and Renter First Name has been supplied and there is no exact 
match on Renter Last Name, there is no match. 

c. If a Renter Last Name and Renter First Name has been supplied and there is an exact 
match on Renter Last Name and not an exact match on Renter First Name, the Renter 
Last Name with the closest Renter First Name is considered a match. 





d. If a Renter Last Name and Claim Number has been supplied and there is an exact match 
on Renter Last Name and not on Claim Number, the closest match on Renter Last Name 
and the closest match on Claim Number greater than the Claim Number provided is 
considered a match. 



2. If the USER supplies one or more of the following fields, the above result set will position to 
closest match of Customer Files based on: Renter Last Name, Renter First Name, and/or Claim 
Number. 

3. This search capability will include all available Open and Closed Rentals for searching. 

4. Any empty fields signify the search should not limit the result set by that field. 

5. Any Customer File present in the result set will contain a link to the appropriate use case based on 
the current status of the reservation or rental. 

1.7 Extension Points 

1 7. 1. 1 MA-10 Authorized a Request 

If the customer file were an unauthorized reservation or ticket, the system would enter the 
Authorization use case to allow the USER to authorize this Customer File. 

1. 7. 1.2 MA-12 Extend Rental 

If the customer file were an authorized ticket or an action item of extension status, the system 
would enter the Extend Rental use case to allow the USER to extend this Customer File. 

1. 7. 1.3 MA-13 Change Authorization 

If the customer file were an authorized reservation or ticket not requiring any immediate action, 
the system would enter the Change Authorization use case to allow the USER to authorize this ' 
Customer File. 

1.7.1.4 MA-07 Additional Charges 

The Additional Charges use case will be used to add special charges to the reservation being 
created by the USER (e.g., CDW). Any Additional Charges captured should be returned and 
applied to the reservation. The existence of Additional Charges should be reflected on the 
reservation screen. 

1.7.1.5 MA-08 View Car Class 

The View Car Class use case will be used to allow the USER to view details about and select a car 
class to apply to a reservation. Details will include the average number of passengers and luggage 
items that can be served by a vehicle in the specific car class. The car class selected by the USER 
should be applied to the reservation. 



1.7.1.6 Invoicing - BI-01 -Handle Unapproved Invoices & BI-02-Pay Approved Invoices & BI-03 
Reject an Invoice 

At step 5, the USER may elect to view approved invoices, unapproved invoices, or rejected 
invoices. Upon completion of this process, the USER should be returned back to step 5 of the 
Basic Flow. 





2. Screen Design 

A definition of the screen Iayout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

2.1 Find a Customer (tab) 

This screen will allow the USER to view the rental. 

2,1.1 Find a Customerjt ah ) <^j> 



Automated Rental Management System 



Claims Office: j jg Handling for |~ 



A| 



lome back, Fitzgerald, Neil. 



in Items, click the column title 
ite. click " DATE RECEIVED" ! 



of your chosen sorting method 



■-15-00 




2.1.2 Customer (tab) 



List Box 



Renter's first name 
Insurance claim num ber 
Adjuster's last name 
Last date authorized 



Ins. Claim number 



LAST AUTH DAY 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. 

2.1.3.1 Search 

When clicked, the will search for any records that match the criteria listed. 
2.2 Customer File - Closed Items 

This screen will allow the USER to view the rental when closed. 



2.2.1 Screen Layout - Customer File - Closed Items 




2.2.2 Customer File - Closed Items 















Actual Days. 


— utput 





actual days rented 


Item Quantity 


Invoicing Section Only 


@ 


Output 




Actual Rate Rented 


Item Rate 


Invoicing Section - Actual Rental only 




Output 


8 


Amount charged 


Item Amount 


Invoicing sections, Actual Rental only 


Billed Period: 


Output 


30 


Billing start date, end 


Item Quantity 


Invoicing section only 


t0 






date and number of 






(_days) 






days 








Output 


3 


Number of days 


Item Quantity 


Invoicing, Actual Rental Section only 








authorized 






Sales Tax ( %) 


Output 


— 


Sales Tax 


Item Description 


Invoicing, Actual Rental section only 


Billed Period: 


Output 


30 


Billing start date, end 


Bill to End Date 


Invoicing section only 


t0 






date and number of 






( days) 






_days 






Billed Period: 


Output 


30 


Billing start date, end 


Bill to Start Date 


Invoicing section only 


- — ~ — *° 






date and number of 






( " a y s ) 


— 




_days 






Federal ID" 


— LEH 




Federal ID Number 


Federal ID Number 


Only shown in Invoicing sections 


Invoice Date: 


Output 


— — 
10 


Invoice Date 


Record Add Date 


Only used in the invoice sections. 


Reference: 


Output 


32 


Reference Number 


Invoice Number 


Only in the invoice sections 


Amount Received 


Output 


8 


Amount Received 


Total Amount 


Invoicing, Actual Rental sections only 










Received 




Total Charges: 


Output 


8 


Total Charges 


Total Ticket Charges 


Invoicing, Actual Rental Section only 


Total Due: 


Output 


8 


Total Due 


Total Amount Due 


Invoicing, Actual Rental sections only 


Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 










_. Nam . e 


Name 




Authorized Period: 


Output 


30 


Authorized Start Date 


Start Date + End 


Only in invoicing sections 


to 








Date + Days 




- — - — * 








authorized-detail 




_ays) 













-j^ — 


Output 





Message Creation Date 


Add Date 





essageto ranc 


Output 


50 


Message Text 


NOTE 




Location: 












Notebook 


Output 




Message Text 


NOTE 


N/A. 


Authorized Class: 


Output 


_20 — 


Car Class Name 


Vehicle Class 




Current Class: 


Output 


20 


Car Class Name 


Vehicle Class 


N/A. 


Claim Number: 


Output 


11 


Claim Number 


Insurance Claim 












Number 




Claim No. 


Output 


30 


Claim Number 


Insurance Claim 












Number 




Daily Rate/Max. 


Output 


10 


Daily Policy Rate and 


Dollars Per Day 


Invoicing section only 


Dollars 






Maximum Policy Rate 


Covered + Max $ 












Covered 




Direct Bill Percent 


Output 


4 


Direct Bill Percent 


Bill To % 


Invoicing sections only 


Direct Bill Percent 


Output 


8 


Direct Bill Percent 


Bill To % 


Invoicing sections Actual Rental only 




Output 


30 


Rental Location Branch 


Rental Location 










Name 






Days/Rate 


Output 


6 


Rental Location Rate 


Number Of Days 


N/A. 








and number of days 


Authorized 


















Days/Rate 


Output 


6 


Rental Location Rate 


Vehicle Rate 


N/A. 








and number of days 






@ 


Output 


7 


Rental Rate per day 


Rate Charged 


Invoicing section only 


Rental Period: 


Output 


30 


Rental Start 


Start Date + End 


Invoicing sections only 


to 








Date + 




( days) 








CALCULATED 




Rental Date 


Output 


10 


Rental Start Date 


Start Date 




Start Date 


Output 


10 


Start Date of rental 


Start Date 




Insured Name: 


Output 


30 


Insured's Name 


First Name + Last 












Name 






Output 


30 


Rental Location 


Address Line + 


N/A. 








Address 


Address Line2 






Output 


25 


Rental Location City 


City 


N/A. 








N ? m .--.- 








Output 


10 


Rental Location Postal / 


Zip Code 


N/A. 








Zip Code 








Output 


3 


Rental Location State / 


State 


N/A. 








Province Code 








Output 


13 


Rental Location 


Telephone Number 


N/A. 








Telephone Number 






Date of Loss: 


Output 


10 


Date of Loss 


Date Of Loss 






Output 


_ 2 9....-_ 


Renter City Name 


City 






Output 


10 


Renter Postal / Zip 


Zip Code 










Code 








Output 


3 


Renter State / Province 


State 










Code 








Output 


30 


Renter Street Address 


Address Line 




Renter Email: 


Output 


20 


Renter's Email 


Day Phone 




Home Phone: 


Output 


16 


Renter's Home Phone 


Renters Night Phone 












+ Renters Night 












Phone Extensin 




Renter Infomation: 


Output 


30 


Renter's Name 


First Name + Last 


N/A. 










Name 




Renter Name: 


Output 


30 


Renter's Name 


First Name + Last 












Name 




Owner's Vehicle 


Output 


4 


Renter's Vehicle Year, 


Renter Vehicle Year 










Make and Model 


+ Renter 












Make/Model 




Work Phone: 


Output 


16 


Renter's Work Phone 


Day Phone + Renters 
















Repair Facility: 


Output 


20 


Body Shop Name 


Repair Facility Name 




Phone Number: 


Output 


16 


Body Shop Phone 


Telephone Number 










Number 








Output 


20 


Repair Faciity City 


City 






Output 


3 


Repair Facility State 


State 






Output 


7 


Repair Facility Zip 


Zip Code 










Code 








Output 


10 


Amount charged 


CALCULATED 


Invoicing sections only 















Total authorized 
Includes Tax & 
Surcharge 


Output 


g 


Total authorized 
amount 


CALCULATED 




Renter Type 


Output 


15 


Claim Type 


claim type 
description 




Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 




Vehicle Condition 


Output 


15 


Loss Type 


loss type description 




Renter Email: 


Output 


20 


Renter's Email 


renter email 





2.2.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.2.3.1 Previous 

When clicked, the USER will be taken back to the use case from where they came 

2.2.3.2 Printer Friendly Version 

When clicked, the system will bring up a screen that only shows the particular invoice for which 
you clicked this button. The USER may print from this screen 

2.2.3.3 Top of page 

When clicked, the USER will be taken to the top of the current page. 



2.3 Search Results 

This screen will allow the USER to view the rental when closed. 

2. 3. 1 Screen Layout - Search Results — c v f~£~ ^ 
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Last Date 


Output 


10 


Authorization Date 






Status 


List Box 


10 


Contract Status 


Status Code 




authorized 












adj. last name 




15 








Adjuster Name: 


Output 


20 


Adjuster Name 


First Nam + Last 
F^rstName + L 




Handling for: 


List Box 


15 


Handlin forAd uster — 
Name'" 8 ^ 


Name ^ ^ 




Fjlc Type 


Output 


15 


litems 


Status Description 




confirmation 
number 




52 


Confirmation Number 


Transmission Code 




Claim Number 


Output 


30 


Claim Number 


Insurance Claim 


Populated by the data matching the 
search criteria 


claim number 


Input 


30 


claim number 


Insurance Claim 
Number 




Loss Date 


Output 


10 


Date of Loss 


Date Of Loss 




first name 


Input 


15 


Renter's First Name 


First Name 




last name 




15 


Renter's Last Name 


Last Name 




Renter's Name 


Output 


30 


Renter's Name 


First Name + Last 


Returned data from the search criteria 


Claims Office: 


List Box 


5 


Office ID 


external organization 
abbreviated name 




You requested a 
search for: 


Output 


30 


Search Criteria 


NOT STORED 


This field will be populated by the 
criteria used to search for a particular 

This field may be a Last Name, First 
Name, Claim Numer, Confirmation 
Number, Adjuster Last Name or 
Status. 

The data in this fiel 



2.3.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity 

2.3.3.1 Search Again 

When clicked, the system will re-search the database after the USER has entered new or additional 



2.3.3.2 Top of page 

When clicked, the USER will be taken to the top of the current page. 



13 




2.3.3.3 View Next 10»> 

When clicked, the system will display the next 10 items that match the search criteria 

3. Application Operations 
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Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 Add Date 



Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NEADDT 


Label Name 


Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.12 Address Line 


Entity 


ARM: Rental Location Master 


Column Name 


LOADL1 


Label Name 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.13 Address Line 


Entity 


ARM: Renter Detail 


Column Name 


RKADL1 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.1.4 Address Line2 


Entity 


ARM: Rental Location Master 


Column Name 


LOADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.15 Bill To % 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZBTPC 


Label Name 


Bill To % 


System Name 




Data Type 


DECIMAL(3) 


Attribute Definition 






4.16 Bill to End Date 


Entity 


A4 Invoice Header 


Column Name 


I1BTDT 


Label Name 


Bill to End Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.7 Bill to Start Date 


Entity 


A4 Invoice Header 


Column Name 


I1SRDT 


Label Name 


Bill to Start Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.8 Branch 


Entity 


ARM: Rental Location Master 


Column Name 


Branch 


Label Name 


Branch: 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.19 City 


Entity 


ARM: Rental Location Master 


Column Name 


LOCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.10 City 


Entity 


ARM: Renter Detail 


Column Name 


RKCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.11 City 


Entity 


ARM: Repair Detail 


Column Name 


RUCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 
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Attribute Definition 



4.1.12 claim type code 



Entity 


AUTHORIZATION EXTENSION 


Column Name 


clm_typ_cde 


Label Name 


claim type code: 


System Name 


CLMTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The claim type code defines the different Authorization claim types. For 
example: Insured, Claimant, Uninsured Motorist, etc. 


4. 1. 13 claim type description 


Entity 


CLAIM TYPE 


Column Name 


elm typ dsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definition of the claim type code 
which defines the different Authorization claim types. For example: 
Insured, Claimant, Uninsured Motorist, etc. 



4.1.14 company identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


cmpyid 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each unique 
occurrence of an Individual, External Organization, and Internal 
Organization (Business Party). 



4.1.15 Date Of Loss 



Entity 


ARM: Renter Detail 


Column Name 


RKLSDT 


Label Name 


Date Of Loss 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.1.16 Day Phone 



Entity 


ARM: Renter Detail 


Column Name 


RKDYPH 


Label Name 


Day Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 
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4.1.17 Days authorized-detail 



Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NEAUDY 


Label Name 


Days authorized-detail 


System Name 




Data Type 


DECIMALS) 


Attribute Definition 




4.178 Dollars Per Day Covered 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZ$PDY 


Label Name 


Dollars Per Day Covered 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.1.19 End Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZENDT 


Label Name 


End Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4. 1.20 external organization identifier 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier: 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The external organization identifier is a surrogate key assigned to each 
unique occurrence of an External Organization. Examples: body shops, 
vehicle manufacturers, insurance companies, leasing accounts, credit unions, 
dealerships, or government agencie 



4.1.21 Federal ID Number 



Entity 


A4 Invoice Header 


Column Name 


I1FETX 


Label Name 


Federal ID Number 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 
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4.1.22 First Name 



Entity 


ARM: Adjustor Master 




Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 




Attribute Definition 




4.123 First Name 


Entity 


ARM: Insured Detail 


Column Name 


IRFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.124 First Name 


Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.125 Group 


Entity 


ARM: Rental Location Master 


Column Name 


Group 


Label Name 


Group Number 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.26 Insurance Claim Number 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.127 Invoice Number 


Entity 


A4 Invoice Header 


Column Name 


I1INNO 




Label Name 


Invoice Number 


System Name 




Data Type 


CHAR(20) 





| Attribute Definition | 


4.1.28 LAST AUT DAY 


Entity 


A4 Cross Reference 


Column Name 


X4LADT 


Label Name 


LAST AUT DAY 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.29 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.30 Last Name 


Entity 


ARM: Insured Detail 


Column Name 


IRLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.31 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.32 loss type code 


Entity 


AUTHORIZATION EXTENSION 


Column Name 


loss_typ_cde 


Label Name 


loss type code: 


System Name 


LOSSTYPCDE 


Data Type 


DEC(3,0) 


Attribute Definition 


The loss type code defines the different loss categories when an Insurance 
Company authorizes a Rental. For example: Theft, Drivable, Repairable, 
Non-drivable, Non-repairable, Totaled. 




4.1.33 loss type description 



Entity 


LOSS TYPE 


Column Name 


loss_typ_dsc 


Label Name 


loss type description: 


System Name 


LOSSTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type code which 
defines the different loss categories when an Insurance Company authorizes 
a Rental. For example: Theft, Drivable, Repairable, Non-drivable, Non- 
repairable, Totaled. 



4.1.34 Max $ Covered 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSMAX 


Label Name 


Max $ Covered 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 





4.1.35 message ecars indicator 



Entity 


AUTHORIZATION MESSAGE 


Column Name 


msg_ecars_ind 


Label Name 


message ecars indicator: 


System Name 


MSGECARIND 


Data Type 


CHAR(1) 


Attribute Definition 


The message ecars indicator indicates whether the message is sent/received 
from the ecars system. 



4.136 NOTE 



Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 





4.137 Number Of Days Authorized 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZAUDY 


Label Name 


Number Of Days Authorized 


System Name 




Data Type 


DECIMAL(3) 


Attribute Definition 





4.138 Rate Charged 



1 Entity | ARM: Authorization(Claim Info) 




J 




Column Name 


AZRTCH 


Label Name 


Rate Charged 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.1.39 Record Add Date 


Entity 


A4 Invoice Header 


Column Name 


I1ADDT 


Label Name 


Record Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4.1.40 Rental Location 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZRNLC 


Label Name 


Rental Location 


System Name 




Data Type 


CHAR(10) 


Attribute Definition 




4.1.41 renter email 


Entity 


RENTER EXTENSION 


Column Name 


rentr eml 


Label Name 


renter email: 


System Name 


RENTREML 


Data Type 


CHAR(70) 


Attribute Definition 


The email address of the renter. 


4.1.42 Renter Make/Model 


Entity 


ARM: Renter Detail 


Column Name 


RKVHMM 


Label Name 


Renter Make/Model 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.43 Renter Vehicle Year 


Entity 


ARM: Renter Detail 


Column Name 


RKVHYR 


Label Name 


Renter Vehicle Year 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 
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4. 1.44 Renters Day Phone Extension 



Entity 


ARM: Renter Detail 


Column Name 


RKDYEX 


Label Name 


Renters Day Phone Extension 


System Name 




Data Type 


NUMERIC(4) 


Attribute Definition 




4.1.45 Renters Night Phone 


Entity 


ARM: Renter Detail 


Column Name 


RKNTPH 


Label Name 


Renters Night Phone 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.46 Renters Night Phone Extensin 


Entity 


ARM: Renter Detail 


Column Name 


RKNTEX 


Label Name 


Renters Night Phone Extensin 


System Name 




Data Type 


NUMERJC(4) 


Attribute Definition 




4.1.47 Repair Facility Name 


Entity 


ARM: Repair Detail 


Column Name 


RURFNM 


Label Name 


Repair Facility Name 


System Name 




Data Type 


CHAR(35) 


Attribute Definition 




4. 1.48 standard message description 


Entity 


STANDARD MESSAGE 


Column Name 


stdmsgdsc 


Label Name 


standard message description: 


System Name 


STDMSGDSC 


Data Type 


CHAR(50) 


Attribute Definition 


The standard message description is a lexical definition for standard message 
code which defines a predefined message which is applicable to specific 
activity type codes. For example: "Authorization confirmed on &Date with 
Reservation Number &Resnumber" 


4.1.49 Start Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSTDT 




Label Name 


Start Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.150 State 



Entity 


ARM: Rental Location Master 


Column Name 


LOSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 





4.1.51 State 



Entity 


ARM: Renter Detail 


Column Name 


RKSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 





4.1.52 State 



Entity 


ARM: Repair Detail 


Column Name 


RUSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 





4. 1.53 Status Description 



Entity 


ARM: ARMS/400 Cross Reference Status Table File 


Column Name 


XUSTDS 


Label Name 


Status Description 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 





4.1.54 Telephone Number 



Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 







Entity 


ARM: Repair Detail 


Column Name 


RUPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 





4.1.56 Total Amount Due 



Entity 


A4 Invoice Trailer 


Column Name 


I3BL$$ 


Label Name 


Total Amount Due 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 





4.1.57 Total Amount Received 



Entity 


A4 Invoice Trailer 


Column Name 


I3RC$$ 


Label Name 


Total Amount Received 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.1.58 Total Ticket Charges 


Entity 


A4 Invoice Trailer 


Column Name 


I3TO$$ 


Label Name 


Total Ticket Charges 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.1.59 Transmission Code 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NETRCD 


Label Name 


Transmission Code 


System Name 




Data Type 


CHAR(l) 


Attribute Definition 




4.160 Vehicle Class 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHCS 


Label Name 


Vehicle Class 


System Name 




Data Type 


CHAR(2) 





4.1.61 Vehicle Rate 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHRT 


Label Name 


Vehicle Rate 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.1.62 Zip Code 


Entity 


ARM: Rental Location Master 


Column Name 


LOZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 




4.163 Zip Code 


Entity 


ARM: Renter Detail 


Column Name 


RKZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 




4.164 Zip Code 


Entity 


ARM: Repair Detail 


Column Name 


RUZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 
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1 . Handle Unapproved Invoices Use Case 

1.1 Brief Description 

The Handle Unapproved Invoices use case describes how the Adjuster would review invoices and approve 
them for payment. The use case will then describe the processes the Adjuster will follow in the case where 
the Adjuster is the one that is actually paying the invoice. 

1 .2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The ADJUSTER will use this case to approve and either pay unapproved invoices or 
send them on to a PROCESSOR for payment. 

1.3 Pre-Conditions 

• The ADJUSTER must be logged into the ARMS Web system. 

• The ADJUSTER'S office must be set up for individual approval of invoices. 

• The ADJUSTER must be able to handle invoices. 

1 .4 Flow of Events 

The Flow of Events will include the necessary steps for an ADJUSTER to approve and pay invoices. 




14.2 Basic Flow 

1 . The ADJUSTER will view the detail of the invoice. 

2. If the ADJUSTER chooses to pay the invoice immediately, execute subflow 1 .4.2.3 - Pay a Single 
Invoice. Otherwise continue the Basic Flow. 

3 . The ADJUSTER will approve the invoice. 

4. The system will mark the invoice approved. 

5. If the ADJUSTER pays their invoices, then the invoice will be added to their payment list. If a 
PROCESSOR pays their invoices, then the invoice will be added to the PROCESSOR'S payment 
list. 

6. The system will update the ARMS Web database. 

7. If this is the last or only invoice in the action items list, then continue to step eight of the Basic 
Flow. Otherwise, the use case ends. 

8. The system will check to see if the ADJUSTER'S office is set up for individual payment or bulk 
payment. 

• If the ADJUSTER'S office is set up for individual payment execute subflow 1.4.2.1, 
Individual Pay. 

• If the ADJUSTER'S office is set up for bulk payment execute subflow 1 .4.2.2, Bulk Pay. 
1.4.2.1 Individual Payment List 

1 . The system will display instructions for paying the invoices individually and a summary list 
of all the invoices just approved by the ADJUSTER. 

2. For each invoice on the payment list, the ADJUSTER may enter the associated check number. 

3. The ADJUSTER will submit the payment list to the system. 

4. The system will mark the invoice paid 

5. The system will update the ARMS Web database. 

6. This ends the use case. 

14.2.2 Bulk Payment List 

1 . The system will display instructions for paying the invoices in bulk and a summary list of all 
the invoices just approved by the ADJUSTER. 

2. The ADJUSTER may enter the check number of the check that is paying all the invoices on 
the payment list. 

3. The ADJUSTER will submit the payment list to the system. 

4. The system will mark the invoice paid 

5. The system will update the ARMS Web database. 

6. This ends the use case. 

1.4.2.3 Pay a Single Invoice 

1 . The ADJUSTER may enter the check number for the invoice being paid. 

2. The system will mark the invoice paid 

3. The system will update the ARMS Web database. 

4. This ends the use case. 

1.4.3 Alternative Flows 

1.4.3. 1 Selected Action Item is Payment List 

At step one of the Basic Flow, if the action item being worked is the "Payment List" action item, 
then the ADJUSTER will be taken immediately to step one of section 1 .4.2.1 if they are set up for 
individual pay, or step one of section 1 .4.2.2 if they are set up for bulk pay. 

14.3.2 Reject an Invoice 

At step one in the Basic Flow, the ADJUSTER may choose to reject the invoice. The rejection 
process is executed using extension point BI-03 - Reject an Invoice. 





1.4.3.3 View Customer File 

At Individual Payment List or Bulk Payment List, the ADJUSTER may choose to view detail 
information about the rental. The view rental detail process is executed using extension point 
MA- 19 - View Customer File. 



1.4.3.4 Print a Single Invoice 

At step one in the Basic Flow, the ADJUSTER may choose to print the invoice. If they so choose, 
they may also print the rental history. The system will display a printer friendly screen and the 
ADJUSTER will choose to print via their browser window. Upon printing, the ADJUSTER will 
choose to return to the step one of the Basic Flow by hitting the "back" button on the web 
browser. 

14.3.5 Print an Invoice List 

At step one in section 1.4.2.1, Individual Pay, or section 1.4.2.2, Bulk Pay, the ADJUSTER may 
choose to print the invoice list of all invoices on the Payment List. If they so choose, they may 
also print the rental history for all invoices. The system will display a printer friendly screen and 
the ADJUSTER will choose to print via their browser window. Upon printing, the ADJUSTER 
will choose to return to the step one of section 1.4.2.1 if the ADJUSTER is set up for Individual 
Pay, or section 1.4.2.2 if the ADJUSTER is set up for Bulk Pay. 

14.3.6 Skip Invoice 

At step three in the Basic Flow, the ADJUSTER may choose to skip the invoice in question and 
handle it at a later time. The ADJUSTER will be taken to the next action item on their action item 
list. The status of the invoice should not be changed by the ARMS Web system. 

14.3.7 Payment by PROCESSOR 

If the ADJUSTER is only responsible for approving the invoice, then, after step four in the Basic 
Flow, the system will make the approved invoice an action item for the PROCESSOR(S) 
responsible for paying the ADJUSTER'S invoices. This ends the use case. Payment by 
PROCESSOR is handled via Functional Specification BI-02 - Pay Approved Invoices. 

14.3.8 Amount Being Approved Exceeds USER'S Authon'zation Limits 

When a USER attempts to approve an invoice for payment, the system will check to see if the 
amount due on the invoice is greater than the USER'S authorization amount. If the amount due is 
greater than the USER'S limit, the system will not allow the approval and will request that the 
USER transfer the invoice to another user with authorization limits that are great enough to 
approve the invoice. 

14.3.9 Change Claim Number 

At step one in the Basic Flow, if the status is "rejected" and if the profile allows, the ADJUSTER 
may choose to change the claim number associated with an invoice. Once a claim number has 
been updated, the ADJUSTER will continue with step four of the basic 

1.5 Post-Conditions 

• If the use case was successful and the ADJUSTER is responsible for paying invoices, the approved 
invoices should be marked as paid in the ARMS Web system. 

• If the use case was successful and the ADJUSTER is only responsible for approving invoices, then the 
approved invoices should be marked as adjuster approved in the ARMS Web system. 

1.6 Special Requirements 

The additional requirements of the business use case are included here. These are requirements not covered 
by the flow as they have been described in the sections above. 





1.6.1 ARMS Web Routes Invoices 



Before an ADJUSTER receives an invoice to be approved, the ARMS Web system will look at the 
invoicing criteria for the owning office and owning adjuster and make a determination as to whether the 
invoice is auto approved or adjuster approved. If an invoice is auto approved, the invoice will always be 
assigned to a processor for payment without it ever being sent to an adjuster for approval. The payment 
method may be either bulk or individual payment. 

1.6.2 Includes Tax and Surcharge Data Field 

On the invoice next to the authorized amount, the field "Includes Tax and Surcharge" will be displayed 
next to the Authorized total if that total should include taxes and surcharges. This will occur in two events. 
For an insured, if the authorized amount is less than the policy daily amount, the authorized total will 
include taxes and surcharges up to the policy daily amount. For a claimant, the authorized amount will 
always include taxes and surcharges, without limit, until the rental is terminated by the ADJUSTER. 

1.6.3 Data Fields to Assist with Future Releases or Customer Integration 

It must be possible to capture the following information at some point in the future because of either 
planned future releases or customer integration. 

• Amount Being Paid on Each Invoice 

1.7 Extension Points 

An extension point indicates a link between this use case and another use case. Extension points associated 
with the use case are indicated below. Clicking on the extension point will open the related use case. 

1. 7. 1 BI-03-Reject an Invoice 

The Reject an Invoice Functional Specification is used to reject a specific invoice to Enterprise 
due to missing required information or an incorrect amount on the bill. Upon completion of the 
Reject an Invoice Functional Specification, the ADJUSTER should be returned to step six of the 
Basic Flow in the Handle Unapproved Invoices Functional Specification. Any previously 
approved invoices should still be approved in the system. The rejected invoice should be marked 
as rejected by the system. The Handle Unapproved Invoices Functional Specification will only 
allow for one invoice to be rejected at a time. 

1. 7.2 MA-19-View Rental Detail 

The View Rental Detail Functional Specification is used to review the rental history in regards to a 
specific rental. Upon completion of the View Rental Detail Functional Specification, the 
ADJUSTER should be returned to step four of the Basic Flow in the Handle Unapproved Invoices 
Functional Specification. Any previously approved invoices should still be approved in the 
system. 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Invoicing - Individual Payment 

This screen will allow the user to choose to view the invoice selected in the action items list. They will 
choose to either pay this invoice immediately (pay now), or choose to add it to a payment list for payment 
later in conjunction with all their other invoices. They may also choose to print the invoice from this page 
They may also optionally choose to print the rental history. The user may choose to change the claim 
number. Finally the user may choose to skip this invoice and leave it until later for review. 
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2.1.2 Invoicing - Individual Payment Screen Design 





Output 












30 


Rental Location's 
Mailing Street Address 


Address Line + 
Address Line2 






Output 


15 


Line Item Charge 
Description 


Item Description 


This line may repeat multiple times 
depending on the number of taxes and 
surcharges that apply. 




Output 


15,2 


Lint Item Charge 
Amount 


Item Amount 


Line Item Charge Qty * Line Item 
Charge Amount. This line may repeat 
multiple times depending on the number 
of taxes and surcharges tat apply. 


Claim No: 


Input 


15 


Claim Number 


Insurance Claim 
Number 




Invoice Date: 


Output 


10 


Invoice Date (Ecar's 
Ticket Date) 


Record Add Date 




Reference: 


Output 


20 


Invoice ID 


Invoice Number 


Rental Group ID + Rental Branch ID + 
ECARS Ticket Number 


Please include 
this reference 
number on your 
check 


Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number 


Federal ID: 


Output 


30 


Location's Federal Id. 


Federal ID Number 




Federal ID 


Output 


30 


Location's Federal ID 


Federal ID Number 




Amount Received 


Output 


15,2 


Amount of rental 
charges received 


Total Amount 
Received 





Total Due: 


*- 


15,2 


Total Amount Due from 
Ins. Company 


Total Amount Due 




Total Charges: 


Output 


15,2 


Total Rental Ticket 
Charges 


Total Ticket Charges 




Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 
Name 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


150 


Messages 


NOTE 


This field will repeat multiple lines for 
all diary notes (messages) for this 
reservation. 




Output 


10 


Authorization 
Termination Date 


End Date 




to 


Output 


10 


Authorization 
Termination Date 


End Date 




Direct Bill 
Percent 


Output 


15,0 


Authorized Bill 
percentage 


Bill To % 




Direct Bill 
Percent: 


Output 


15,0 


Authorized Bill 


Bill To % 




Authorized 
Period: 


Output 


10 


Authorized Start Date 


Start Date 




Billed Period: 


Output 


10 


Authorized Start Date 


Start Date 




Claim Number 


Input 


15 


Claim Number 


Insurance Claim 
Number 


Will be pre-filled with the claim number 
curently on the authorization. 


to 


Output 


10 


Close date of Rental 
Ticket 


End Date 1 





se 1.0 















Policy: Daily 

Rate/Max 

Dollars: 


Output 


15,2 


Policy Daily Maximum 
Maximum 


Dollars Per Day 




Policy: Daily 

Rate/Max 

Dollars: 


Output 


15,2 


Amount + Policy 
Maximum 






Rental Period: 


Output 


10 


Start date of Rental 
Ticket 


Start Date 




Insured Name 


Output 


30 




Name 




For 


Output 






F.rstName.Last 










Mailing City, State and 
Zip Code 


Code 






Output 




Mailing Street Address 


Addres Line2 








15 


Rental Location's 


Telephone Number 






Output 


30 


Rental Location's 
Mailing City, State, and 


City 






Output 


30 


Rental Location's 
Mailing City, State, and 


State 










Rental Location's 
Mailing City, State, and 


Zip Code 






Output 


30 


Rental Location's 


Address Line + 
Address Line2 






Output 


15 


Rental Location's Phone 


Telephone Number 


This field is repeated for each invoice in 
the payment list. 


Renter 


"Output 




Renters Name 


— 

First Name + Last 
Name 




( 


Output 


5 


Days 


CALCULATED 




( 


Output 


5 


Number of authorized 


CALCULATED 




( 


Output 


5 


Number of Rental Days 


CALCULATED 







Output 




Total Amount Due from 
Ins. Company 


CALCULATED 


Total Charges - Amount Received 


Number of 
Authorized Dates 
+"@" + 

authorized Daily 
Rate + 7day=" 


Output 


15,2 


Total Authorized 
surcharge 


CALCULATED 


Number of Aurhorized Days * 


Total authorized 
includes Tax & 
Surcharge 


Output 


15,2 


Total authorized 
Amount with Tax and 
surcharge 


CALCULATED 


(Number of authroized Days * 
Authroized Daily Rate) + Calculated Tax 
and surcharge 















Number of Rental 
Days + "@" + 
ECAR's Ticket 
Daily Rate + 
7day=" 


Output 


15,2 


Total Ticket Rental 
Amount before tax and 


CALCULATED 


Number of Rental Days * ECARS Ticket 
Daily Rate 


Claim Type: 


Output 


10 


Claim Type 


claim type 




Claims Office: 


Output 


3 


Office Id 


external organization 


The claims office id which the user is 
currently process work for. 


Vehicle 
Condition 


Output 


20 


Loss Type 


loss type description 




Rental 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 




Send Payment 
To: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 




Check Number 
for you payment: 


Input 


20 


Check Number 


check number 





2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2. 1.3. 1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 
invoice. 

2.1.3.2 REJECT 

When clicked, the user will be taken to the Reject Invoice process. 

2.13.3 PAYNOW 

When clicked, the system will edit the current information. If the edit passes, the invoice 
will be marked as paid and the data files updated. If the validation fails, the user will be 
returned to the current screen with the errors highlighted. 

2.1.3.3.1 The system will validate that the user has an authorization limit high enough to 

approve the invoice. If not, the system will generate an error and ask the USER to 
transfer the invoice. 

2.1.3.4 ADD TO PAYMENT LIST 

When clicked, the system will edit the current information for check number and claim 
number. If the edit passes, the invoice will be marked as approved and will be added to 
the ADJUSTER'S payment list and the user will be returned to the Review List process. 

2.1.3.5 SKIP» 

When clicked, the user will be advanced to the next action item to be processed and the 
current invoice will remain unchanged (un-approved). 




2.1.3.6 Top of Page 

When clicked, the user will be taken to the top of the current invoice page. 

2.13.7 Transfer File 

When clicked, the system will present a list of users that have authorization limits greater 
than the amount due on the invoice. The USER may then choose one user from this list 
to which they may transfer the file. 

2.13.8 Policy Information 

Policy Information will only be shown under the Authorized Section if the claim type is 
NOT claimant. 



Invoicing - Approval 

This screen will allow the user to choose to view the invoice selected in the action items list. They may 
choose to approve the invoice payment. This will add the invoice to the PROCESSOR(S) that are 
responsible for paying the ADJUSTER'S invoices. The user may also choose to skip this invoice and leave 
it until later for review. They may choose to print the invoice from this page. They may also optionally 
choose to print the rental history. Finally, the user may choose to change the claim number. 





2. 2. 2 Invoicing Approval 





Output 


152 


Line item Charge 
Amount 


Item Amount 


Line Item Charge Qty * Line Item 
Charge Amount. 

This line may repeat multiple times 
depending on the number of taxes and 
surcharges that apply. 




Output 


15 


Line Item Charge 
Description 


Item Description 


This line may repeat multiple times 
depending on the number of taxes and 
surcharges that apply. 


Claim No: 


Output 


15 


Claim Number 


Insurance Claim 
Number 




Claim Number 


Input 


15 


Claim Number 


Insurance Claim 
Number 


Will be pre-filled with claim number 
curently on authorization. 


To 


Output 


10 


Close Date of billing of 
Rental Ticket 


Bill to End Date 




Invoice Date: 


Output 


10 


Invoice Date (ECARs 
Ticket Date) 


Record Add Date 




Reference 


Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number 


Federal ID: 


Output 


30 


Location's Federal Id. 


Federal ID Number 




Billed Period 


Output 


10 


Start date of billing of 
Rental Ticket 


Bill to Start Date 




Amount 
Received: 


Output 


15,2 


Amount of rental 
received. 


Total Amount 
Received 




Total Due 


Output 


15,2 


Total amount due from 
Ins. Company 


Total Amount Due 




Total Charges: 


Output 


15,2 


Total Rental Ticket 
Charges 


Total Ticket Charges 




Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


50 


Messages 


NOTE 


This field will repeat multiple lines for 
all diary notes (messages ) for a 
reservation 


To 


Output 


10 


Authorization 
Termination Date 


End Date 




Direct Bill 


Output 


15,0 


Authorized Bill 
percentage 


Bill To % 




Direct Bill 
Percent 


Output 


15,0 


Authorized Bill 
percentage 


Bill To% 




Authorized 
Period: 


Output 


10 


Authorized Start Date 


Start Date 




To 


Output 


10 


Close Date of Rental 
Ticket 


End Date 




Policy: Daily 

Rate/Max 

Dollars 


Output 


15,2 


Policy Daily Maximum 
Amount + Policy 
Maximum 


Dollars Per Day 
Covered 






Policy: Daily 

Rate/Max 

Dollars 










Output 




Amount + Policy 


Max $ Covered 




Rental Period: 


Output 


10 


Start date of Rental 
Ticket 


Start Date 




Insured Name: 


Output 






First Name + Last 




For: 


Output 






First Name + Last 
Name 


Renter's Last Name + Renter's First 
Name 




Output 


30 


MaiHng Ory State and 
Zip Code 


City + State + Zip 
Code 


Mailing City + Mailing State + Mailing 
Zip 




Output 


30 


Rental Location's 
Mailing Street Address 


Address Line + 
Address Line2 






Output 


15 


Phone Number 


Telephone Number 




Date of loss: 


Output 


20 


Date of loss 


Date Of Loss 




Renter 


Output 


30 


Renter's name 


First Name + Last 


Renter's Last Name + Renter's First 


( 


Output 


5 


Number of Authorized 
Days 


CALCULATED 


Total number of authorized rental days 


( 


Output 


5 


Number of Billed Days 


CALCULATED 




( 


Output 


5 


Number of Rental Days 


CALCULATED 


Total number of authorized Rental Days 


Total Due: 


Output 


15,2 


Total Amount Due from 
Ins. Company 


CALCULATED 


Total Charges - Amount Received 


Number of 
Authorized 

Authorized 
Daily Rate + 
"/day=" 


Output 


15,2 


Total authorized 
amount before tax and 
surcharge 


CALCULATED 


Number of Authorized Days * 
Authorized Daily Rate 


Total authorized 
Surcharge 


Output 


15,2 


Total Authorized 
Amount with tax and 
surcharge 


CALCULATED 


(Number of authorized Days * 
Authorized Daily Rate) + (Calculated 
Tax and surcharge) 


Rental Days + 
"@" + ECAR's 
Ticket Daily 
Rate + 7day=" 






Total Ticket Rental 
Amount before tax and 


CALCULATED 


Number of Rental Days * ECARS Ticket 
Daily Rate 


Claim Type: 


Output 


10 


Claim Type 


claim type 
description 


Claimant, Insured, etc. 


Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


The claims office id which the user is 
currently process work for. 


Rental 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 





This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 
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2.2.3.1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 
invoice. 

2.2.3.2 REJECT 

When clicked, the user will be taken to the Reject Invoice process. 

2.2.3.3 APPROVE FOR PAYMENT 

When clicked, the currently displayed invoice status will be marked as approved and the 
user will be taken to the next Action Item. 

• The system will validate that the user has an authorization limit high enough to 
approve the invoice. If not, the system will generate an error and ask the USER to 
transfer the invoice. 

• Another adjuster has not already approved the invoice. 

2.2.3.4 SKIP» 

When clicked, the user will be advanced to the next selected action item to be processed 
and the current invoice will remain unchanged (un-approved). 

2.2.3.5 Top of Page 

When clicked, the user will be taken to the top of the current invoice page. 

2.2.3.6 Transfer File 

When clicked, the system will present a list of users that have authorization limits greater 
than the amount due on the invoice. The USER may then choose one user from this list 
to which they may transfer the file. 

2. 2. 3. 7 Policy Information 

Policy Information will only be shown under the Authorized Section if the claim type is 
NOT claimant. 




Individual Payment List 

This screen provides the user with information on what the system expects them to do, and requests a 
check number that will be used to pay each invoice. The user may also choose to print the invoices, and 
optionally print the rental history in addition to the invoices. The user may choose not to process the 
payment list at this time, in which case the payment list will be added to the user's action items list. 



2.3.1 



Screen Layout -invoicing PymtListshtml — i-fie_Y\5 Uft^S 



Automated Rental Management Syste" 



Claims Office: 001 Handling for: Yourself 

IriVOiCingjor Weber, Andrew Claim no. 755849322-001 




Authorized Period: 02/10/00 to 03/01700 (20 days) 



Total au 



loriied: 



Reference: PPGM D073082 
Invoice Date: 02/1CWJ0 
Federal ID: 4800791835 



Vehicle Condition: Non-Dnveable 
Date of Loss: 02/05/00 
Insured Name: Smith. Bob 



Actual Rental 

Rental Period: O2/10/D3 to 03/01/00 {20 days) 
Billed Period: 02/10/00 to 03431/00 (20 days) 
Actual Days: 

20 @ $22.99/day = $505.78 
100% 
$533.13 



Total Ch; 
Amount I 



Receiy 



K.13 
















Claim Number 




15 


Claim Number 


Insurance Claim 
Number 


Will be pre-filled with claim number 
currently on authroization. This field is 
repeated for eahc invoice in the payment 
list. 

This field is repeated for each invoice in 
the payment list. 


Invoice Date 


Output 


10 


Invoice Date (EC ARS 
Ticket Date) 


Record Add Date 


This field is repeated for each invoice in 
the payment list. 


Invoice: 


Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number 

This field is repeated for each invoice in 
the payment list. 


Please include this 
reference number on 
your check: 


Output 


20 


Invoice ID 


Invoice Number 


Rental Group ID + Rental Branch ID+ 
ECARS Ticket number. This field is 
repeated for each invoice in the payment 
list. 


Federal ID 


Output 


30 


Location's Federal ID 


Federal ID Number 


This field is repeated for each invoice in 
the payment list. 


Total Amount: 


Output 


15,2 


Total amount due from 
Ins. Company 


Total Amount Due 


Total Charges - Amount Received 

This field is repeated for each invoice in 
the payment list. 


Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


30 


Insured's Name 


First Name + Last 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location 's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 
the payment list. 




Output 


12 


Rental Location 
Telephone Number 


Telephone Number 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City, State and 
Zip Code 


City + State + Zip 
Code 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City State and 


City + State + Zip 
Code 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 
the payment list. 








Date of loss 


Date Of Loss 


This field is repeated for each invoice in 
the payment list. 


Invoice 


Output 


5 


Invoice List Number 


CALCULATED 


This field is repeated for each invoice in 
the payment list. 

Count 


Claim type 


Output 


10 


Claim Type 


claim type 
description 


This field is repeated for each invoice in 
the payment list. 
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Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


currently process work for. 


Vehicle Condition 


Output 


10 


Loss Type 


loss type description 


This field is repeated for each invoice in 
the payment list. 


Remit to: 


Output 


30 


Rental Locaiton's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Rental: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Send Payment to: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Enter the check 
number of your 
payment here: 




20 


Check Number 


check number 


This field is repeated for each invoice in 
the payment list. 



Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.3.3. 1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 



2.3.3.2 CONFIRM PAYMENT 

When clicked, system will mark the reservation as paid and update the database. The 
update will be passed to the Arms system. 

2.3.3.3 PAY LATER 

When clicked, the user will be returned to view list and the requests will remain 
unchanged. 

2.3.3.4 Top of Page 

When clicked, the user will be taken to the top of the current invoice page. 




Bulk Payment List 

This screen provides the user with information on what the system expects them to do, and requests a 
check number that will be used to pay each invoice. The user may also choose to print the invoices, and 
optionally print the rental history in addition to the invoices. The user may choose not to process the 
payment list at this time, in which case the payment list will be added to the user's action items list. 
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Automated Rental Management System 




Rental llrdnih Location: 
tiff) I arii-r Pd 
i,...,ILo u .s.MOUU40001 
(314)512-0294 



Reference: PPGM D073082 
Invoice Date: f 
Federal ID: 4800791835 



id: 02/10/00 to 03/01/00 (2C 



lys) 



Direct Bill Percent: 



Claim Number 156 987 54821 j 
Claim Type: Claimant 
Vehicle Condition: Non-Driveable 
& Surcharges Date of Loss: 02/05/DO 

Insured Name: Smith, Bob 



Rental Period: 02/1000 to 03*1/00 (20 days) 
Billed Period: 02/1CW30 to 03*11/00 (20 days) 

20@l22.99/day= (505.78 

Direct Bill Percent 100% 

Total Charges: (536.13 

Amount Recerred: J0.00 

Total Due: $536.13 



sewation for Weber. Andrew 2/21/00 
ry Note. Marty Sarussi. 2/21/00 
:ension request, 204/00 



2. 4. 2 Bulk Payment List 



Claim Number 


Input 


15 








Claim Number 


Insurance Claim 
Number 


Will be pre-filled with claim number 
currently on authorization. This field is 
repeated for each invoice in the payment 


Invoice Date 


Output 


10 


Invoice Date (ECARS 
Ticket Date) 


Record Add Date 


This field is repeated for each invoice in 
the payment list. 


Please include 
number on your 


Output 


20 


Invoice ID 


Invoice Number 


Rental Group ID + Rental Branch ID+ 
ECARS Ticket number This field is 
repeated for each invoice in the payment 


Invoice: 


Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number This field is 

list. 


Federal ID 


Output 


30 


Location's Federal ID 


Federal ID Number 


This field is repeated for each invoice in 


Total Amount: 


Output 


15,2 


Total amount due from 


Total Amount Due 


Total Charges - Amount Received This 
payment list. 


Handling For: 


Output 


30 


Handling for Adjuster's 


F.rstName.Last 


name. The name of the adjuster to which 




Output 


30 


Insured's Name 


First Name + Last 


This field is repeated for each invoice in 
the payment list. 




Output 




Mailing Street Address 


Address Line2 


This field is repeated for each invoice in 
the payment list. 




Output 


12 


Rental Location 


Telephone Number 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Zip Code 


City + State + Zip 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Mailing City State and 


Code 


the payment list. 




Output 


30 


Rental Location's 
Mailing Street Address 


Address Line + 


This field is repeated for each invoice in 


Date of loss 


Output 


10 


Date of loss 


Date Of Loss 


This field is repeated for each invoice in 


Invoice 


Output 


5 


Invoice List Number 


CALCULATED 


This field is repeated for each invoice in 
the payment list. Count 


Claim type 


Output 


10 


Claim Type 


claim type 


This field is repeated for each invoice in 
the payment list. 


Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


The claims office id which the user is 
currently process work for. 


Vehicle 
Condition 


Output 


10 


Loss Type 


loss type description 


This field is repeated for each invoice in 
the payment list. 


Remit to: 


Output 


30 


Rental Locaiton's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Send Payment 
to: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 



Rental: 


Output 


30 


Rental Location's 


accounting name 


This field is repeated for each inv 


lice in 1 








Accounting Name 




1 the payment list. 





2.4.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.4.3. 1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 
invoices. 

2.4.3.2 CONFIRM PAYMENT 

When clicked, the system will mark the reservation as paid and update the database. The 
update will be passed to the Arms system. The user will then be returned to the next 
action item or the Action Items screen if no more action items exist. 

2.4.3.3 PAYLATER 

When clicked, the user will be returned to Action Items and the request will remain 
unchanged. 

2.4.3.4 Top of Page 

When clicked, the user will be taken to the top of the payment list. 




3. Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document. 

3.1 Get Unapproved Invoices (Adjuster Id) 

The build unapproved invoice list operation finds all the invoices, that need approval, for the 
specified adjuster. 

3.2 Approve Invoice (Invoice Number) 

The approve invoice operation marks the specified invoice as approved. This invoice is now 
ready to be paid. 

3.3 Get Approved Invoices (Adjuster Id) 

The build approved invoice list operation finds all the approved invoices for the specified adjuster. 

3.4 Get Invoice Detail (Invoice Number) 

The build invoice detail operation gets the relevant invoice information for the specified invoice 
number. 

3.5 Pay Invoice (Invoice Number, Check Number) 

The pay invoice operation records the check number specified by the adjuster against the specified 
invoice and marks the invoice as paid. 
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Data Fields 

Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4. 1. 1 accounting name 



Entity 


OFFDRJB OFFICE DIRECTORY BRANCH MASTER 


Column Name 


acctgnam 


Label Name 


Accounting Name 


System Name 




Data Type 


VARCHAR(8) 


Attribute Definition 





4.1.2 action item assigned date 



Entity 


ACTION ITEM 


Column Name 


actn item assn dte 


Label Name 


action item assigned date: 


System Name 


AITMASGNDT 


Data Type 


DATE 


Attribute Definition 


The action item assigned date is the date the action item was established and 
assigned to an administrator or adjustor. 



4.1.3 action item complete date 



Entity 


ACTION ITEM 


Column Name 


actn_item_cmpl_dte 


Label Name 


action item complete date: 


System Name 


AITMCMPLDT 


Data Type 


DATE 


Attribute Definition 


The action item complete date is the date the action item was completed by 
an administrator or adjustor. 



4. 1.4 action item effective date 



Entity 


ACTION ITEM 


Column Name 


actn item eff dte 


Label Name 


action item effective date: 


System Name 


AITMEFFDT 


Data Type 


DATE 


Attribute Definition 


The action item effective date is the date the action item will become 
effective. 



4.1.5 action item status code 



Entity 


ACTION ITEM 


Column Name 


actn item stat cde 


Label Name 


action item status code: 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 


The action item status code defines the status of this action item. For 
example: 
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4. 1. 6 action item type code 



Entity . 


ACTION ITEM 


Column Name 


actnitemtypcde 


Label Name 


action item type code: 


System Name 




Data Type 


DEC(3,0) 


Attribute Definition 


The action item type code defines specific tasks/action items associated with 
the Rental Authorization/Reservation activities accomplished by adjustors 
and administrators when contracting an insured with a replacement vehicle. 
For example: Closing an Of 


4. 1. 7 action item type description 


Entity 


ACTION ITEM TYPE 


Column Name 


actn item typ dsc 


Label Name 


action item type description: 


System Name 




Data Type 


CHAR(40) 


Attribute Definition 


The action item type description is a lexical definition of an action item type 
code which defines specific tasks/action items associated with the Rental 
Authorization/Reservation activities accomplished by adjustors and 
administrators when contracting an 


4. 1. 8 action related adjuster code 


Entity 


ACTION ITEM 


Column Name 


actnreladjrcde 


Label Name 


Adjuster Code 


System Name 


ARADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The action related adjuster codeis the adjuster code of the adjustor/user 
which requires completion of some action item work activity such as an 
office closing and adjusters/users who need to be moved to another office. 


4.1.9 action related company identifier 


Entity 


ACTION ITEM 


Column Name 


actnrelcmpyid 


Label Name 


ARMS Profile ID 


System Name 


ARCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The action related company identifier is the company identifier of the 
adjustor/user which requires completion of some action item work activity 
such as an office closing and adjusters/users who need to be moved to 
another office. 


4.1.10 Address Line 


Entity 


ARM: Rental Location Master 


Column Name 


LOADL1 


Label Name 






System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.11 Address Line2 



Entity 


ARM: Rental Location Master 


Column Name 


LOADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.12 Adjuster Code 



Entity 


ARM: Adjuster Master 


Column Name 


ALAACD 


Label Name 


Adjuster Code 


System Name 




Data Type 


CHAR(10) 


Attribute Definition 





4.1.13 ARMS Profile ID 



Entity 


ACTION ITEM 


Column Name 


ALCUID 


Label Name 


ARMS Profile ID 


System Name 




Data Type 


CHAR(5) 


Attribute Definition 


The ARMS Profile ID is the company identifier used to uniquely define an 
authorization. 



4.1.14 ARMS Profile ID 



Entity 


ARM: Adjuster Master 


Column Name 


ALCUID 


Label Name 


ARMS Profile ID 


System Name 




Data Type 


CHAR(5) 


Attribute Definition 





4.1.15 assigned to adjuster code 



Entity 


ACTION ITEM 


Column Name 


assgntoadjrcde 


Label Name 


Adjuster Code 


System Name 


AADJRCDE 


Data Type 


CHAR(IO) 


Attribute Definition 


The assigned to adjuster code is the adjuster code of the administrator or 
adjuster's who is assigned the action item. 
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4. 1. 16 assigned to company identifier 



Entity 


ACTION ITEM 


Column Name 


assgntocmpyid 


Label Name 


ARMS Profile ID 


System Name 


ACMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The assigned to company identifier is the company identifier of the 
administrator or adjuster's who is assigned the action item. 


4 .1.17 Bill To % 




Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZBTPC 


Label Name 


Bill To % 


System Name 




Data Type 


DECIMALS) 


Attribute Definition 




4.1.18 Bill to End Date 


Entity 


A4 Invoice Header 


Column Name 


I1BTDT 


Label Name 


Bill to End Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 





4.179 Bill to Start Date 



Entity 


A4 Invoice Header 


Column Name 


I1SRDT 


Label Name 


Bill to Start Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 






4.1.20 check number 



Entity 


RENTAL INVOICE PAYMENT 


Column Name 


chk nbr 


Label Name 


check number: 


System Name 


CHKNBR 


Data Type 


DEC(11,0) 


Attribute Definition 




4.1.21 City 


Entity 


ARM: Rental Location Master 


Column Name 


LOCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 






4. 1.22 claim type description 



Entity 


CLAIM TYPE 


Column Name 


clmtypdsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definition of the claim type code 
which defines the different Authorization claim types. For example: 
Insured, Claimant, Uninsured Motorist, etc. 



4.1.23 company identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


cmpyid 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each unique 
occurrence of an Individual, External Organization, and Internal 
Organization (Business Party). 



4.1.24 company structure level code 



Entity 


ACTION ITEM 


Column Name 


cmpystrct lvl cde 


Label Name 


company structure level code: 


System Name 


CMPYSLVLCD 


Data Type 


DEC(3,0) 


Attribute Definition 


The external organization structure level code identifies the kind or type of 
internal organizations of the external organizations which Enterprise Rent- 
A-Car does business with. Such as: Corporation, Branch Claims Office, 
Region, Area, Subregion, etc. 



4.1.25 Customer Transaction ID 



Entity 


ACTION ITEM 


Column Name 


AZCUTI 


Label Name 


Customer Transaction ID 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 


The Customer Transaction ID is the authorization transaction identifier 
which along with a company identifier uniquely define an authorization. 



4.1.26 Date Of Loss 



Entity 


ARM: Renter Detail 


Column Name 


RKLSDT 


Label Name 


Date Of Loss 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 








r 



4.1.27 Dollars Per Day Covered 



Entity 


ARM: Authorization(CIaim Info) 


Column Name 


AZ$PDY 


Label Name 


Dollars Per Day Covered 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 




4.128 End Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZENDT 


Label Name 


End Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4. 1.29 external organization abbreviated name 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(IO) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 


4.1.30 external organization identifier 


Entity 


ALTERNATE ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier: 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each unique 
occurrence of an Individual, External Organization, and Internal 
Organization (Business Parry). 


4.1.31 Federal ID Number 


Entity 


A4 Invoice Header 


Column Name 


I1FETX 


Label Name 


Federal ID Number 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 





4.1.32 First Name 
Entity I ARM: Adjuster Master 
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Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.33 First Name 


Entity 


ARM: Insured Detail 


Column Name 


IRFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(l5) 


Attribute Definition 




4.1.34 First Name 


Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.35 handled by adjuster code 


Entity 


ACTION ITEM 


Column Name 


handl by adjr cde 


Label Name 


Adjustor Code 


System Name 


HNDADJRCDE 


Data Type 


CHAR(IO) 


Attribute Definition 


The handled by adjustor code is the adjustor code of the administrator or 
adjuster's who is handling the action item. 


4. 1.36 handled by company identifier 


Entity 


ACTION ITEM 


Column Name 


handlbycmpyid 


Label Name 


ARMS Profile ID 


System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handled by company identifier is the company identifier of the 
administrator or adjuster's who is handling the action item. 


4.1.37 handling for adjuster code 


Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


handl for adtr cde 


Label Name 


handling for adjustor code: 


System Name 


HNDADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The handling for adjustor coder is the adjustor code of an adjustor/user who 
is handling authorization activities for another adjustor/user in the ARMS 





I Web application. 



4.1.38 handling for company identifier 



Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


handlforcmpyid 


Label Name 


handling for company identifier: 


System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handling for company identifier is the company identifier used to 
uniquely identify an adjustor/user who is handling authorization activities 
for another adjustor/user in the ARMS Web application. 



4.1.39 Insurance Claim Number 



Entity 


A4 Invoice Header 


Column Name 


I1CLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.40 Insurance Claim Number 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.41 Invoice Number 



Entity 


A4 Invoice Header 


Column Name 


I1INNO 


Label Name 


Invoice Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.142 Item Amount 



Entity 


A4 Invoice Detail 


Column Name 


I2IT$$ 


Label Name 


Item Amount 


System Name 




Data Type 


DECIMAL(7,2) 


Attribute Definition 





4.1.43 Item Description 



Entity 


A4 Invoice Detail 


Column Name 


I2ITDS 





Label Name 


Item Description 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.1.44 Item Quantity 



Entity 


A4 Invoice Detail 


Column Name 


I2ITQY 


Label Name 


Item Quantity 


System Name 




Data Type 


DECIMAL(5) 


Attribute Definition 





4.1.45 Item Rate 



Entity 


A4 Invoice Detail 


Column Name 


I2ITRT 


Label Name 


Item Rate 


System Name 




Data Type 


DECIMAL(7,2) 


Attribute Definition 





4.146 Last Name 



Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.47 Last Name 




Entity 


ARM: Insured Detail 


Column Name 


IRLSNM 




Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 




Attribute Definition 




4.1.48 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





[ Entity 



4. 1.49 loss type description 



| loss typeT 
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Column Name 


lossjypdsc 


Label Name 


loss type description: 


System Name 


LOSSTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type code which 
defines the different loss categories when an Insurance Company authorizes 
a Rental. For example: Theft, Drivable, Repairable, Non-drivable, Non- 
repairable, Totaled. 



4.1.50 Max $ Covered 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZ$MAX 


Label Name 


Max $ Covered 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 





4.1.51 NOTE 



Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 





4. 1.52 Number Of Days Authorized 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZAUDY 


Label Name 


Number Of Days Authorized 


System Name 




Data Type 


DECIMALS) 


Attribute Definition 




4.1.53 Record Add Date 


Entity 


A4 Invoice Header 


Column Name 


I1ADDT 


Label Name 


Record Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4. 1.54 related office identifier 


Entity 


ACTION ITEM 


Column Name 


re! ofc id 


Label Name 


related office identifier: 


System Name 


RELOFCID 


Data Type 


DEC(11,0) 


Attribute Definition 


The related office identifier is the identifier of the office responsible for the 





4. 1.55 Remittance Reference # 



Entity 


A4 Remit Reference No. 


Column Name 


Q5RMNO 


Label Name 


Remittance Reference # 


System Name 




Data Type 


NUMER1C(6) 


Attribute Definition 




4.1.56 Request Type 


Entity 


ACTION ITEM TYPE 


Column Name 


XURSTP 


Label Name 


Request Type 


System Name 


XURSTP 


Data Type 


CHAR(1) 


Attribute Definition 


The request type is a code from the ARMS system which identifies whether 
adjusor action is necessary for an authorization and what type of action. 


4.157 Start Date 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSTDT 


Label Name 


Start Date 


System Name 




Data Type 


NUMER1C(8) 


Attribute Definition 




4.158 State 


Entity 


ARM: Rental Location Master 


Column Name 


LOSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.159 Status Code 


Entity 


ACTION ITEM TYPE 


Column Name 


XUSTCD 


Label Name 


Status Code 


System Name 


XUSTCD 


Data Type 


CHAR(1) 


Attribute Definition 


The status code is a code from the ARMS system which identifies whether 
an authorization is a reservation, a ticket, unauthorized, invoiced, paid, etc. 


4.1.60 Telephone Number 


Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 




Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.61 Total Amount Due 


Entity 


A4 Invoice Trailer 


Column Name 


I3BL$$ 


Label Name 


Total Amount Due 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.1.62 Total Amount Received 


Entity 


A4 Invoice Trailer 


Column Name 


I3RC$$ 


Label Name 


Total Amount Received 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4. 1. 63 Total Billed to Others 


Entity 


A4 Invoice Trailer 


Column Name 


I30T$$ 


Label Name 


Total Billed to Others 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4. 1. 64 Total Ticket Charges 


Entity 


A4 Invoice Trailer 


Column Name 


I3TO$$ 


Label Name 


Total Ticket Charges 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 





4.1.65 Vehicle Rate 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZVHRT 


Label Name 


Vehicle Rate 




System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 





4.166 Zip Code 
1 Entity [ ARM: Rental Location Master 
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System Name 

Data Type 

Attribute Definition 





5. Questions and Answers 



Issue Number: 256 



Question: The calculation for authorized limit when displaying the invoice detail does not take 
bill to percent into account when all the following conditions are true: 

Policy Maximum = 0 

Policy Daily > 0 

Vehicle Rate > 0 

Vehicle Rate < Policy Daily 
or all the following conditions are true: 

Policy Maximum > 0 

Policy Daily = 0 

Vehicle Rate > 0 

In all other cases, the amount is multiplied by the bill to percent to get the authorized limit. 
Is this calculation correct ? 



Status: Pending 



Resolution: 3-14-00, DSE-Need to follow up with author to get an further understanding of 
question. 

3-23-00, Issue Mtg, Will get addressed in current state and fix. 



Issue Number: 257 



Question: This is a presentation issue. The adjuster name on the invoice detail screen will not 
show up in certain cases. This code is in the *INZSR sub routine and needs some investigation of 
scenarios to determine the exact flaw. 



Status: Closed - Resolved 



Resolution: 3-14-00, DSE-Need to follow up with author to get an further understanding of 
question. 
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1. Pay Approved Invoices Use Case 



1.1 Brief Description 

The Pay Approved Invoices use case describes how the PROCESSOR would review and pay invoices in 
the ARMS Web system. 

1.2 Use Case Actors 

The following actors will interact with this use case: 

• PROCESSOR - The PROCESSOR will use this use case to pay approved invoices. 

1.3 Pre-Conditions 

• The PROCESSOR must be logged into the ARMS Web system. 

• The PROCESSOR'S office must be set up to handle processor payment of invoices. 

• The PROCESSOR must be authorized to handle invoices. 

1.4 Flow of Events 

The Flow of Events will include the necessary steps for a PROCESSOR to review and pay invoices. 





1.4.2 Basic Flow 

1 . The PROCESSOR will view their payment list. 

2 . The system will check to see if the PROCESSOR' S office is set up for individual payment or bulk 
payment. 

• If the PROCESSOR'S office is set up for individual payment execute subflow 1 .4.2. 1 , 
Individual Pay. 

• If the PROCESSOR'S office is set up for bulk payment execute subflow 1 .4.2.2, Bulk Pay. 

1.4.2.1 Individual Pay 

1 . The system will display instructions for paying the invoices individually and a summary list 
of all the invoices on the PROCESSOR'S payment list. 

2. For each invoice on the payment list, the PROCESSOR may enter the associated check 
number. 

3 . The PROCESSOR will submit the invoices to the system. 

4. The system will mark the invoices paid. 

5 . The system will update the ARMS Web database. 

6. This ends the use case. 

1.4.2.2 Bulk Pay 

1 . The system will display instructions for paying the invoices in bulk and a summary list of all 
the invoices on the PROCESSOR'S payment list. 

2. The ADJUSTER may enter the check number of the check that is paying all the invoices on 
the payment list. 

3. The PROCESSOR will submit the invoices to the system. 

4. The system will mark the invoices paid. 

5. The system will update the ARMS Web database. 

6. This ends the use case. 

1.4.3 Alternative Flows 

1.4.3.1 View Customer File 

At step one of Section 1.4.2.1, Individual Pay, or Section 1.4.2.2, Bulk Pay, the PROCESSOR 
may choose to view detail information about the rental. The view rental detail process is executed 
using extension point MA- 19 - View Customer File. 

1.4.3.2 Return an Invoice 

At step one of Section 1.4.2.1, Individual Pay or Section 1.4.2.2, Bulk Pay the PROCESSOR may 
choose to return any invoice to the ADJUSTER. The PROCESSOR may enter a message to 
explain why they returned the invoice. The returned invoice should be given a status of returned 
invoice. The invoice will then become an action item for the owning ADJUSTER to review and 
correct 

1.4.3.3 Print an Invoice List 

At step one in section 1.4.2.1, Individual Pay, or section 1.4.2.2, Bulk Pay, the PROCESSOR may 
choose to print the invoice list of all invoices on the Payment List. If they so choose, they may 
also print the rental history for all invoices. The system will display a printer friendly screen and 
the PROCESSOR will choose to print via their browser window. Upon printing, the 
PROCESSOR will return to the step one of section 1.4.2.1 if the PROCESSOR is set up for 
Individual Pay, or section 1.4.2.2 if the PROCESSOR is set up for Bulk Pay. 



1.5 Post-Conditions 

• If the use case was successful the accepted invoices should be marked as paid in the ARMS Web 




system. 

• If the use case was unsuccessful, the system state is unchanged. 

1.6 Special Requirements 

The additional requirements of the business use case are included here. These are requirements not covered 
by the flow as they have been described in the sections above. 

1.6.1 ARMS Web Routes Invoices 

Before an ADJUSTER receives an invoice to be approved, the ARMS Web system will look at the 
invoicing criteria for the owning office and owning adjuster and make a determination as to 
whether the invoice is auto approved or adjuster approved. If an invoice is auto approved, the 
invoice will always be assigned to a processor for payment without it ever being sent to an 
adjuster for approval. 

1.6.2 Data Fields to Assist with Future Releases or Customer Integration 

It must be possible to capture the following information at some point in the future because of 
either planned future releases or customer integration. 

• Amount Being Paid on Each Invoice 

1.6.3 Claim Number is Editable on the Invoice 

If a company is set up for EDI transmission of invoices to the company's claim system, that 
company must have the ability to change the claim number on the invoice. 

1.7 Extension Points 

1.7.1 MA-19-View Customer File 

The View Customer File Functional Specification is used to review the rental history in regards to 
a specific rental. Upon completion of the View Customer File Functional Specification, the 
ADJUSTER should be returned to step one of Section 1 .4.2. 1 , Individual Pay, or Section 1 .4.2.2, 
Bulk Pay in the Handle Unapproved Invoices Functional Specification. Any previously approved 
invoices should still be approved in the system. 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 Invoicing - Individual Payment List 

This screen will allow the user to enter a check number for each invoice and notify Enterprise that they 
have processed the payment. 




Issue^v 1.0 I 
Issue Date7 s tQ/2Q^00 



2.1.2 Individual Payment List 















Claim Number 


Input 


15 


Claim Number 


Insurance Claim 
Number 


Will be pre-filled with claim number 
currently on authroization. This field is 
repeated for eahc invoice in the payment 
list. 

This field is repeated for each invoice in 
the payment list. 


Invoice Date 


Output 


10 


Invoice Date (ECARS 
Ticket Date) 


Record Add Date 


This field is repeated for each invoice in 
the payment list. 


Please include this 
reference number 


Output 


20 


Invoice ID 


Invoice Number 


Rental Group ID + Rental Branch ID+ 
ECARS Ticket number. This field is 
repeated for each invoice in the payment 
list. 


Invoice: 


Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number 

This field is repeated for each invoice in 
the payment list. 


Federal ID 






Location's Federal ID 


Federal ID Number 


This field is repeated for each invoice in 
the payment list. 








Total amount due from 
Ins. Company 


Total Amount Due 


Total Charges - Amount Received 

This field is repeated for each invoice in 
the payment list 








Name 


First Name + Last 
Name 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 










First Name + Last 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location 's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 
the payment list. 




Output 


12 


Rental Location 


Telephone Number 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City, State and 
Zip Code 


City + State + Zip 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City State and 


City + State + Zip 
Code 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 


Date of loss 


Output 


10 


Date of loss 


Date Of Loss 


This field is repeated for each invoice in 
the payment list. 




Output 


5 


Invoice List Number 


CALCULATED 


This field is repeated for each invoice in 
the payment list. 

Count 


Claim type 


Output 


10 


Claim Type 


claim type 
description 


This field is repeated for each invoice in 
the payment list 
















Claims Office: 


Output 


3 


Office Id 


external organization 


The claims office id which the user is 
currently process work for. 


Vehicle Condition 


Output 


10 


Loss Type 


loss type description 


This field is repeated for each invoice in 
the payment list. 


Remit to: 


Output 


30 


Rental Locaiton's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Rental: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Enter the check 
number of your 
payment here: 




20 


Check Number 


check number 


This field is repeated for each invoice in 
the payment list. 



Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2. 1.3. 1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 



2.13.2 CONFIRM PAYMENT 

When clicked, system will mark the reservation as paid and update the database. The 
update will be passed to the Arms system. 

2.1.3.3 PAY LATER 

When clicked, the user will be returned to their action item list and the payment list will 
remain unprocessed. 

2. 1.3.4 RETURN TO ADJUSTER 

When clicked, the invoice will be returned to the last adjuster associated with the rental 
before it closed. The invoice will be removed from the list displayed. 

2.13.5 Top of Page 

When clicked, the user will be taken to the top of the current invoice page. 
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Bulk Payment List 

This screen will allow the user to pick which functions that he/she may want to change. 



2. 2. 1 Screen Layout - Bulk Payment List — <yZJLs W (k 





Invoicing - Bulk Payment List 













Claim Number 




15 


Claim Number 


Insurance Claim 
Number 


Will be pre-filled with claim number 
currently on authorization. This field is 
repeated for each invoice in the payment 
list. 


Invoice Date 


Output 


10 


Invoice Date (ECARS 
Ticket Date) 


Record Add Date 


This field is repeated for each invoice in 
the payment list. 


Please include this 
reference number 
on your check: 


Output 


20 


Invoice ID 


Invoice Number 


Rental Group ID + Rental Branch ID+ 
ECARS Ticket number. This field is 
repeated for each invoice in the payment 
list. 




Output 


20 


Invoice Id 


Invoice Number 


Rental Group Id + Rental Branch Id + 
ECARS Ticket Number This field is 
repeated for each invoice in the payment 
list. 


Federal ID 


Output 


30 


Location's Federal ID 


Federal ID Number 


This field is repeated for each invoice in 
the payment list. 


Total Amount: 


Output 


152 


Total amount due from 
Ins. Company 


Total Amount Due 


Total Charges - Amount Received This 
field is repeated for each invoice in the 
payment list. 


Handling For: 


Output 


30 


Handling for Adjuster's 
Name 


First Name + Last 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


30 


Insured's Name 


Last Name 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location 's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 
the payment list. 




Output 


12 


Rental Location 
Telephone Number 


Telephone Number 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City, State and 
Zip Code 


City + State + Zip 
Code 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing City State and 
Zip 


City + State + Zip 
Code 


This field is repeated for each invoice in 
the payment list. 




Output 


30 


Rental Location's 
Mailing Street Address 


Address Line + 
Address Line2 


This field is repeated for each invoice in 
the payment list 


Date of loss 


Output 


10 


Date of loss 


Date Of Loss 


This field is repeated for each invoice in 
the payment list. 


Invoice 


Output 


5 


Invoice List Number 


CALCULATED 


This field is repeated for each invoice in 
the payment list. Count 


Claim type 


Output 


10 


Claim Type 


claim type 
description 


This field is repeated for each invoice in 
the payment list. 


Claims Office: 


Output 


3 


Office Id 


external organization 
abbreviated name 


The claims office id which the user is 
currently process work for. 


Vehicle Condition 


Output 


10 


Loss Type 


loss type description 


This field is repeated for each invoice in 
the payment list. 


Remit to: 


Output 


30 


Rental Locaiton's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 


Send Payment to: 


Output 


30 


Rental Location's 
Accounting Name 


accounting name 


This field is repeated for each invoice in 
the payment list. 





2. 2. 3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.2.3.1 PRINTER FRIENDLY PAGE 

When clicked, the user will be taken to the "Printer Friendly View" of the current 



2.2/3.2 CONFIRM PAYMENT 

When clicked, system will mark the reservation as paid and update the database. The 
update will be passed to the Arms system. 

2.2.3.3 PAY LATER 

When clicked, the user will be returned to their action item list and the payment list will 
remain unprocessed. 

2.2.3.4 RETURN TO ADJUSTER 

When clicked, the invoice will be returned to the last adjuster associated with the rental 
before it closed. The invoice will be removed from the list displayed. 

2.2.3.5 Top of Page 

When clicked, the user will be taken to the top of the current invoice page. 




2.3 Return Invoice to Adjuster r- >_ 

2.3 A Screen Layout;j£tU0M!!]9j>!^^ — 
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^ m ^ r * * " Return Billing 

Return Billing 

You've chosen to return the following invoice. 

Adjuster's Name Renter's Name Claim Number A 

Warner, Kurt Bamvakais.Joho 569873451 %, 

Comments: ^mmmm^^^^^mamm^m^^^^m 



iff' 



z. j.z Return billing 















Claim Number 


Input 


15 


Claim Number 


Insurance Claim 
Number 




Amount 


Output 


15,2 


Total Amount Due from 
Ins. Company 


Total Amount Due 




Adjuster's Name 


Output 


30 


Adjuster's Name 


First Name + Last 


Adjuster's last name + adjuster's first 
name. 


Comments 




50 


Reason Comments 


NOTE 




Renter Name 


Output 


30 


Renter's name 


First Name + Last 


Renter's Last Name + Renter's First 




ComboBox 


50 


Reason For Return 


standard message 
description 





2.3.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.3.3.1 CANCEL 

When clicked, the user will be returned to the Invoicing Approval or Invoicing 
Individual Payment screen from which they came. The invoice will still be displayed 
with the status of the invoice unchanged. 

2.3.3.2 Return to Adjuster 

When clicked, the user will return the invoice to the Adjuster for further instructions and 
the status will show returned invoice. 



3. Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document. 

3.1 Get Approved Invoices (Office Id) 

The get approved invoices operation finds all the approved invoices for the specified office. 

3.2 Get Invoice Detail (Invoice Number) 

The get invoice detail operation gets the relevant invoice information for the specified invoice number. 

3.3 Return Invoice to Approving Adjuster (Invoice Number, Reason Code) 

The return invoice to approving adjuster operation marks the specified invoice so that the approving 
adjuster can review the invoice and re-approve it. 

3.4 Pay Invoice (Invoice Number, Check Number) 

The pay invoice operation records the check number specified by the adjuster against the specified invoice 
and marks the invoice as paid. 



4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 accounting name 


Entity 


OFFDRB OFFICE DIRECTORY BRANCH MASTER 


Column Name 


acctgnam 


Label Name 


Accounting Name 


System Name 




Data Type 


VARCHAR(8) 


Attribute Definition 




4.1.2 action item complete date 


Entity 


ACTION ITEM 


Column Name 


actnitem_cmpl_dte 


Label Name 


action item complete date: 


System Name 


AITMCMPLDT 


Data Type 


DATE 


Attribute Definition 


The action item complete date is the date the action item was completed by 
an administrator or adjuster. 


4. 1.3 action item effective date 


Entity 


ACTION ITEM 


Column Name 


acta item eff dte 


Label Name 


action item effective date: 


System Name 


AITMEFFDT 


Data Type 


DATE 


Attribute Definition 


The action item effective date is the date the action item will become 
effective. 


4. 1.4 action item status code 


Entity 


ACTION ITEM 


Column Name 


acta item stat cde 


Label Name 


action item status code: 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 


The action item status code defines the status of this action item. For 
example: 


4.15 action item type code 


Entity 


ACTION ITEM 


Column Name 


actnitemtypcde 


Label Name 


action item type code: 


System Name 




Data Type 


DEC(3,0) 


Attribute Definition 


The action item type code defines specific tasks/action items associated with 
the Rental Authorization/Reservation activities accomplished by adjusters 




and administrators when contracting an insured with a replacement vehicle. 
For example: Closing an Of 



4,1.6 action item type description 



Entity 


ACTION ITEM TYPE 


Column Name 


actnjtemtypdsc 


Label Name 


action item type description: 


System Name 




Data Type 


CHAR(40) 


Attribute Definition 


The action item type description is a lexical definition of an action item type 
code which defines specific tasks/action items associated with the Rental 
Authorization/Reservation activities accomplished by adjustors and 
administrators when contracting an 


4.1.7 Address Line 


Entity 


ARM: Rental Location Master 


Column Name 


LOADL1 


Label Name 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.1.8 Address Line2 


Entity 


ARM: Rental Location Master 


Column Name 


LOADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 




4.19 ARMS Profile ID 


Entity 


ACTION ITEM 


Column Name 


ALCUTD 


Label Name 


ARMS Profile ID 


System Name 




Data Type 


CHAR(5) 


Attribute Definition 


The ARMS Profile ID is the company identifier used to uniquely define an 
authorization. 


4.1.10 assigned to adjuster code 


Entity 


ACTION ITEM 


Column Name 


assgn to adjr cde 


Label Name 


Adjustor Code 


System Name 


AADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The assigned to adjustor code is the adjustor code of the administrator or 
adjuster's who is assigned the action item. 



4.1.11 assigned to company identifier 



Entity 


ACTION ITEM 


Column Name 


assgntocmpyid 


Label Name 


ARMS Profile ID 


System Name 


ACMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The assigned to company identifier is the company identifier of the 
administrator or adjustor's who is assigned the action item. 



4.1.12 Bill To % 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZBTPC 


Label Name 


Bill To % 


System Name 




Data Type 


DECIMAL(3) 


Attribute Definition 





4.1.13 Branch 



Entity 


A4 Cross Reference 


Column Name 


br id 


Label Name 


Branch: 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 





4.1.14 check number 



Entity 


RENTAL INVOICE PAYMENT 


Column Name 


chk nbr 


Label Name 


check number: 


System Name 


CHKNBR 


Data Type 


DEC(11,0) 


Attribute Definition 





4.1.15 City 



Entity 


ARM: Rental Location Master 


Column Name 


LOCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4.1.16 claim type description 



Entity 


CLAIM TYPE 


Column Name 


clm_typ_dsc 


Label Name 


claim type description: 


System Name 


CLMTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The claim type description is a lexical definition of the claim type code 




which defines the different Authorization claim types. For example: 
Insured, Claimant, Uninsured Motorist, etc. 



4.1.17 company identifier 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


cmpyid 


Label Name 


company identifier: 


System Name 


CMPYID 


Data Type 


DEC(11,0) 


Attribute Definition 


Business Party Identifier is a surrogate key assigned to each unique 
occurrence of an Individual, External Organization, and Internal 
Organization (Business Party). 


4.1.18 company structure level code 


Entity 


ACTION ITEM 


Column Name 


cmpystrctlvlcde 


Label Name 


company structure level code: 


System Name 


CMPYSLVLCD 


Data Type 


DEC(3,0) 


Attribute Definition 


The external organization structure level code identifies the kind or type of 
internal organizations of the external organizations which Enterprise Rent- 
A-Car does business with. Such as: Corporation, Branch Claims Office, 
Region, Area, Subregion, etc. 


4.1.19 Customer Transaction ID 


Entity 


ACTION ITEM 


Column Name 


AZCUTI 


Label Name 


Customer Transaction ID 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 


The Customer Transaction ID is the authorization transaction identifier 
which along with a company identifier uniquely define an authorization. 


4.120 Date Of Loss 


Entity 


ARM: Renter Detail 


Column Name 


RKLSDT 


Label Name 


Date Of Loss 


System Name 




Data Type 


NTJMERIC(8) 


Attribute Definition 




4.1.21 Dollars Per Day Covered 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSPDY 


Label Name 


Dollars Per Day Covered 


System Name 




Data Type 


DECIMAL(5,2) 


Attribute Definition 







4.1.22 End Date 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZENDT 


Label Name 


End Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4. 1.23 external organization abbreviated name 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(10) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 


4.1.24 external organization identifier 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o id 


Label Name 


external organization identifier: 


System Name 


EOID 


Data Type 


DEC(11,0) 


Attribute Definition 


The external organization identifier is a surrogate key assigned to each 
unique occurrence of an External Organization. Examples: body shops, 
vehicle manufacturers, insurance companies, leasing accounts, credit unions, 
dealerships, or government agencie 


4.1.25 Federal ID Number 


Entity 


A4 Invoice Header 


Column Name 


I1FETX 


Label Name 


Federal ID Number 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.126 First Name 


Entity 


ARM: Adjuster Master 


Column Name 


ALFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 







4.1.27 First Name 



Entity 

Column Name 
Label Name 
System Name 
Data Type 
Attribute Definition 

4.1.28 Group 


ARM: Renter Detail 

RKFSNM 

First Name 

CHAR(15) 


Entity 


A4 Cross Reference 


Column Name 


grp id . 


Label Name 


Group Number . . 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.29 handled by adjuster code 


Entity 


ACTION ITEM 


Column Name 


handl by adjr cde 


Label Name 


Adjustor Code 


System Name 


HNDADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The handled by adjustor code is the adjustor code of the administrator or 
adjuster's who is handling the action item. 


4.1.30 handled by company identifier 


Entity 


ACTION ITEM 


Column Name 


handl by cmpy id 


Label Name 


ARMS Profile ID 


System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handled by company identifier is the company identifier of the 
administrator or adjuster's who is handling the action item. 



4.1.31 handling for adjustor code 



Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


handl for adtr cde 


Label Name 


handling for adjustor code: 


System Name 


HNDADJRCDE 


Data Type 


CHAR(10) 


Attribute Definition 


The handling for adjustor coder is the adjustor code of an adjuster/user who 
is handling authorization activities for another adjuster/user in the ARMS 
Web application. 



4.1.32 handling for company identifier 



Entity 


AUTHORIZATION ACTIVITY LOG 


Column Name 


handl for cmpy id 


Label Name 


handling for company identifier: 




System Name 


HNDCMPYID 


Data Type 


CHAR(5) 


Attribute Definition 


The handling for company identifier is the company identifier used to 
uniquely identify an adjustor/user who is handling authorization activities 
for another adjustor/user in the ARMS Web application. 


4.1.33 Insurance 


Claim Number 


Entity 


A4 Invoice Header 


Column Name 


I1CLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.34 Insurance Claim Number 


Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZCLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.35 Invoice Number 


Entity 


A4 Invoice Header 


Column Name 


I1INNO 


Label Name 


Invoice Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.36 Item Amount 


Entity 


A4 Invoice Detail 


Column Name 


I2IT$$ 


Label Name 


Item Amount 


System Name 




Data Type 


DECIMAL(7,2) 


Attribute Definition 




4.1.37 Item Description 


Entity 


A4 Invoice Detail 


Column Name 


I2ITDS 


Label Name 


Item Description 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 






4.138 Item Quantity 



Entity 

Column Name 
Label Name 
System Name 


A4 Invoice Detail . . 

2ITQY 

[tern Quantity 




Data Type 
Attribute Definition 


DECIMALS) _____ 

1 


4.1.39 Item Rate 




Entity 


A4 Invoice Detail 


Column Name 


I2ITRT 


Label Name 


Item Rate 


System Name 




Data Type 


DECIMAL(7,2) 


Attribute Definition 




4.1.40 Last Name 


Entity 


ARM: Adjustor Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.41 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4. 1.42 loss type description 


Entity 


LOSS TYPE 


Column Name 


loss typ dsc 


Label Name 


loss type description: 


System Name 


LOSSTYPDSC 


Data Type 


CHAR(40) 


Attribute Definition 


The loss type description is a lexical definition of the loss type code which 
defines the different loss categories when an Insurance Company authorizes 
a Rental. For example: Theft, Drivable, Repairable, Non-drivable, Non- 
repairable, Totaled. 



4.1.43 Max $ Covered 



Entity 


ARM: Authorization(Claim Info) 


Column Name 


AZSMAX 


Label Name 


Max $ Covered 


System Name 







4.1.44 NOTE 


Entity 


ARM: ARMS/400 Diary Notes File 


Column Name 


NENOTE 


Label Name 


NOTE 


System Name 




Data Type 


CHAR(50) 


Attribute Definition 




4.1.45 Record Add Date 


Entity 


A4 Invoice Header 


Column Name 


I1ADDT 


Label Name 


Record Add Date 


System Name 




Data Type 


NUMERIC(8) 


Attribute Definition 




4. 1.46 related office identifier 


Entity 


ACTION ITEM 


Column Name 


rel ofc id 


Label Name 


related office identifier: 


System Name 


RELOFCID 


Data Type 


DEC(11,0) 


Attribute Definition 


The related office identifier is the identifier of the office responsible for the 




action item. 


4.1.47 Request Type 


Entity 


A4 Cross Reference 


Column Name 


X4RSFG 


Label Name 


Request Type 


System Name 




Data Type 


CHAR(1) 


Attribute Definition 




4.1.48 standard message description 


Entity 


STANDARD MESSAGE 


Column Name 


std msg dsc 


Label Name 


standard message description: 


System Name 


STDMSGDSC 


Data Type 


CHAR(50) 


Attribute Definition 


The standard message description is a lexical definition for standard message 




code which defines a predefined message which is applicable to specific 




activity type codes. For example: "Authorization confirmed on &Date with 




Reservation Number &Resnumber" 



4.149 Start Date 



Entity 


ARM: Authorization(Claim Info) 




Column Name 


AZSTDT 




Label Name 


Start Date 


System Name 




Data Type 


NUMERICS 




Attribute Definition 





4.150 State 



Entity 


ARM: Rental Location Master 


Column Name 


LOSACD 


Label Name 


State 




System Name 




Data Type 


CHAR(2) 


Attribute Definition 


' 



4.15? Status Code 



Entity 


ACTION ITEM TYPE 


Column Name 


XUSTCD 


Label Name 


Status Code 


System Name 


XUSTCD 


Data Type 


CHAR(1) 


Attribute Definition 


The status code is a code from the ARMS system which identifies whether 
an authorization is a reservation, a ticket, unauthorized, invoiced, paid, etc. 



4. 1 52 Telephone Number 



Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 





4.153 Ticket Number 



Entity 


A4 Cross Reference 


Column Name 


X4TKNO 


Label Name 


Ticket Number 


System Name 




Data Type 


CHAR(6) 


Attribute Definition 





4. 1 54 Total Amount Due 



Entity 


A4 Invoice Trailer 


Column Name 


I3BL$$ 


Label Name 


Total Amount Due 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 







4. 7. 55 Total Amount Received 



Entity 


A4 Invoice Trailer 


Column Name 


I3RC$$ 


Label Name 


Total Amount Received 


System Name 




Data Type 


DECDvIAL{9,2) 


Attribute Definition 




4. 1.56 Total Billed to Others 


Entity 


A4 Invoice Trailer 


Column Name 


I30T$$ 


Label Name 


Total Billed to Others 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.1.57 Total Ticket Charges 


Entity 


A4 Invoice Trailer 


Column Name 


I3TO$$ 


Label Name 


Total Ticket Charges 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.158 Zip Code 


Entity 


ARM: Rental Location Master 


Column Name 


LOZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 
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1 . Reject An Invoice Use Case 

1.1 Brief Description 

The Reject an Invoice use case describes how the ADJUSTER would reject an invoice to Enterprise in 
the ARMS Web system. 

1 .2 Use Case Actors 

The following actors will interact with this use case: 

• ADJUSTER - The ADJUSTER will use this use case to reject an invoice. 

1 .3 Pre-Conditions 

• The ADJUSTER'S office must be set up for individual approval of invoices. 

• The ADJUSTER must be set up to approve invoices. 

1.4 Flow of Events 

The Flow of Events will include the necessary steps for an ADJUSTER to reject invoices. 




14.2 Basic Flow 

1 . The ADJUSTER will reject an invoice. 

2. The system will prompt for reject confirmation. 

3 . The ADJUSTER will enter a reject reason for rejecting the invoice. 

4. The ADJUSTER may enter comments to be added to the diary notes. 

5. The ADJUSTER will submit the rejection to the system. 

6. The system will display instructions for achieving resolution on the rejected invoice. 

7. The ADJUSTER will acknowledge that they understand the instructions. 

8. The system will update the ARMS Web database to reflect that the ADJUSTER rejected 
the invoice. 

9. This ends the use case. 

14.3 Alternative Flows 

1.4.3.1 Cancel Rejection 

At steps two through seven of the Basic Flow, the ADJUSTER must have the ability 
to cancel the invoice rejection process. Canceling the rejection should return the 
ADJUSTER to the Invoicing Approval Screen or the Invoicing Individual Payment 
screen. The invoice that was to be rejected should be displayed. The status of the 
invoice should be unapproved. 

1.4.3.2 No Reject Reason Given 

At step three in the Basic Flow; if the ADJUSTER attempts to bypass entering a 
reject reason, they will be prompted to enter one. The ADJUSTER will not be 
allowed to complete the rejection process without providing a reject reason. 

14.3.3 Short Pay 

If the reject reason given in step three of the Basic Flow is a reason that requires a 
short pay, at step five of the Basic Flow the system will display a field for entry of 
the short pay amount. The ADJUSTER will not be allowed to complete the rejection 
process without providing an amount that will be paid. 

Post-Conditions 

• If the use case was successful the invoice will be marked rejected in the ARMS Web system. 

• If the use case was unsuccessful, the status remains unchanged. 

Special Requirements 

The additional requirements of the business use case are included here. These are requirements not 
covered by the flow as they have been described in the sections above. 

1.6.1 Invoices are Initially Auto Approved 

If an ADJUSTER'S invoices are normally auto approved, functionality needs to exist to route invoices 
to them when they are returned to ADJUSTER from the PROCESSOR. This functionality will need to 
override the normal routing processes that exist at the office. 

1.7 Extension Points 

None. 




1.5 
1.6 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 Reject Billing Reason 

This screen will allow the user to begin the rejection process. 



2.1.1 Screen Layout - Reject Billing Reason — <JZz_^ £ijUV~c 

E .50 



Mtp://grace/amsweb/fp/lteiation_1 ZteiectBifngPagel .html 



•^^^J 1 """ Reject Billing 

Reject Billing 

You've chosen to reject the following invoice. 

Adjuster's Name Renter's Name Claim Number 



2.1.2 Reject Billing - Reject Billing Reason 



~1 















Amount 


Output 


10 


Total Amount Due 


CALCULATED 




Number 


Output 


15 


Claim Number 


Insurance Claim 
Number 




Adjuster's 


Output 


30 


Adjuster's Name 


First Name + Last 
Name 


Name of adjuster's to which the invoice 
is assigned 


Comments 


Input 


50 


Message Text 


NOTE 




Name 


Output 


30 


Renter's name 


First Name + Last 
Name 


Renter's Last Name + Renter's First 
Name 


Reason for 


List Box 


20 


Rejection Reasons 


standard message 
description 





2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 



2.1.3.1 CONTINUE 

The system will validate the input from the screen according to the listed business rules. 
If the validation passes, the rejection process will continue. 

The following business rules that must be passed before the USER may continue to the 
next step in the rejection process are the following: 

■ A valid rejection reason must be selected from the drop down box 

■ If the rejection reason selected is "Other" a comment must be entered 

2.1.3.2 CANCEL 

When clicked, the user will be returned to the Invoicing Approval or Invoicing 
Individual Payment screen. The invoice will still be displayed with the status of the 
invoice unchanged. 




2.2 Reject Billing Amount 



2.2.1 Screen Layout- Reject Billing Amount — R^vn_ t , 5 i 



Reject Billing 
Reject Billing 

You've chosen to reject the following invoice. 



Adjuster's Name Renter's Name Claim Number Amount 

Warner, Kurt Bamvakais, John 5698754821 $27 

Amount you are paying: BmUHBBBil 

To complete this process, please contact the 
rental branch location listed below: 
Enterprise Rent-A-Car 
600 New Haven Rd. 
Charlotte, NC 28210 
704-653-2001 



2. 2. 2 Reject Billing - Reject Billing Amount 



f, s o>- 















Claim Number 


Output 


15 


Claim Number 


Insurance Claim 
Number 




Amount 


Output 


15,2 


Invoice Amount 


Total Amount Due 




Adjuster's Name 


Output 


30 


Adjuster's Name 


First Name + Last 
Name 


Name of adjuster's to which the invoice 
is assigned 


Handling For: 


Output 


30 


Handling for Adjuster's 


First Name + Last 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


30 


User's Name 


First Name + Last 


Adjuster's last name + adjuster's first 
name. The name of the current adjuster 
in the system 




Output 


30 


Rental Location 
Address 


Address Line + 
Address Line2 






Output 


30 


Rental Location City, 
State and Zip 


City + State + Zip 
Code 






Output 


15 


Rental Location 
Telephone Number 


Telephone Number 
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Renter's Name 


Output 


30 


Renter's name 


First Name + Last 


Renter's Last Name + Renter's First 


To complete this 
process, please 
contact the 
Enterprise 
Branch listed 


Output 


50 


Rental Location 
Accounting Name 


accounting name 





2.2.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.2.3.1 REJECT INVOICE 

The system will validate the input from the screen. If the validation passes, the invoice 
will be marked as rejected and the Arms Web database will be updated. If an amount 
was entered in the "Amount you are paying" field, then the invoice should be marked 
short paid. 

2.2.3.2 CANCEL 

When clicked, the user will be returned to the Invoicing Approval or Invoicing 
Individual Payment screen. The invoice will still be displayed with the status of the 
invoice unchanged. 



Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document. 

Get Invoice Rejection Reasons (Company id) 

The get invoice rejection reasons gets the predefined rejection reasons for the company. 
Reject Invoice (Invoice Number) 

The reject invoice operation marks the specified invoice as rejected. The rejected invoice 
becomes an action item for the adjuster to handle. 




Data Fields 

Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 accounting name 



Entity 


OFFDRB OFFICE DIRECTORY BRANCH MASTER 


Column Name 


acctg nam 


Label Name 


Accounting Name 




System Name 




Data Type 


VARCHAR(8) 


Attribute Definition 





4.1.2 Address Line 



Entity 


ARM: Rental Location Master 


Column Name 


LOADL1 


Label Name 




System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.13 Address Line2 



Entity 


ARM: Rental Location Master 


Column Name 


LOADL2 


Label Name 


Address Line 


System Name 




Data Type 


CHAR(30) 


Attribute Definition 





4.14 City 



Entity 


ARM: Rental Location Master 


Column Name 


LOCYNM 


Label Name 


City 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 





4. 1 5 external organization abbreviated name 



Entity 


EXTERNAL ORGANIZATION 


Column Name 


e o abbr nam 


Label Name 


external organization abbreviated name: 


System Name 


EOABBRNAM 


Data Type 


CHAR(10) 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used for accounting purposes. 
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4.1.6 First Name 




ARM: Adjuster Master 




ALFSNM 


SbelN^ne 16 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4.1.7 First Name 




Entity 


ARM: Renter Detail 


Column Name 


RKFSNM 


Label Name 


First Name 


System Name 




Data Type 


CHAR(15) 


Attribute Definition 




4. 1.8 Insurance Claim Number 


Entity 


A4 Invoice Header 


Column Name 


I1CLNO 


Label Name 


Insurance Claim Number 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.9 Last Name 


Entity 


ARM: Adjuster Master 


Column Name 


ALLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.10 Last Name 


Entity 


ARM: Renter Detail 


Column Name 


RKLSNM 


Label Name 


Last Name 


System Name 




Data Type 


CHAR(20) 


Attribute Definition 




4.1.11 standard message description 


Entity 


STANDARD MESSAGE 


Column Name 


std msg dsc 


Label Name 


standard message description: 


System Name 


STDMSGDSC 


Data Type 


CHAR(50) 


Attribute Definition 


The standard message description is a lexical definition for standard message 
code which defines a predefined message which is applicable to specific 




\ 




activity type codes. For example: "Authorization confirmed on &Date with 
Reservation Number &Resnumber" 



4.1.12 State 



Entity 


ARM: Rental Location Master 


Column Name 


LOSACD 


Label Name 


State 


System Name 




Data Type 


CHAR(2) 


Attribute Definition 




4.1.13 Telephone Number 


Entity 


ARM: Rental Location Master 


Column Name 


LOPHNO 


Label Name 


Telephone Number 


System Name 




Data Type 


NUMERIC(IO) 


Attribute Definition 




4.1.14 Total Amount Due 


Entity 


A4 Invoice Trailer 


Column Name 


I3BL$$ 


Label Name 


Total Amount Due 


System Name 




Data Type 


DECIMAL(9,2) 


Attribute Definition 




4.1.15 Zip Code 


Entity 


ARM: Rental Location Master 


Column Name 


LOZPCD 


Label Name 


Zip Code 


System Name 




Data Type 


CHAR(9) 


Attribute Definition 





Functional Design Specification 
Callbacks 

Version 1.1 




Callbacks 

1. Callbacks 

1 .1 Brief Description 

This use case describes the process that will perform repair facility callbacks in the ARMS Web system. 
USERs perform repair facility callbacks on each of the rental contracts that are set to expire in the near 
future (or have already expired), to proactively determine if rentals must be extended due to slippage in 
repair facility time estimates. The callback process in the ARMS Web system will retrieve each of the 
rental contracts that will expire in the user-defined period of time, and organize them by repair facility to 
allow the USER to make one phone call to inquire about the potentially multiple vehicles that the repair 
facility is responsible for. 

1.2 Use Case Actors 

All actors will use the use case to retrieve callback lists in the ARMS Web system. All of the following 
actors can be defined generically as a USER: 

• PROCESSOR 

• ADJUSTER 

• COMPANY MANAGER 

For the balance of this use case, all of the above actors will be referred to as USER. 

1.3 Pre-Conditions 

• The USER must be signed-on to the system. 

1.4 Flow of Events 

The Flow of Events includes all the steps necessary to retrieve and manage callbacks in the ARMS Web 
system. 





1.4.2 Basic Flow 

The Basic Flow of the Callbacks use case includes all of the required activities for the USER to 
successfully generate and perform repair facility callbacks in the ARMS Web system. 



1 . The USER selects to perform callbacks from the reporting menu of top navigation. 

2. The system generates a report of all open authorizations for the selected office that will expire the 
next day (have a last authorized day of tomorrow). This list will include any authorizations that 
have already expired, or will expire by the end of business on the following day. 





3. The system displays a summary of repair facilities that have rentals expiring in the specified 
timeframe. The repair facility callback summary must consist of: 

• Repair Facility Name 

• Repair Facility Telephone Number 

• Number of Rental callbacks due to the Repair Facility 



4. The USER selects one or more repair facilities from the repair facility callback summary. 

5. The system displays a summary of the open authorizations that are set to expire for all selected 
repair facilities. The open authorization callback summary will consist of: 

• Renter Name 

• Year/Make/Model of the Renter's Vehicle 

• Driveable Flag (y/n) 

• Number of Days Behind 

• Authorized Days 

• Last Authorized Day 

6. The USER will select a customer file from the list. 

7. The USER will extend into use case MA- 1 2 Extend Authorization. The USER will have the 
ability to extend, add notes, terminate or modify an authorization as proscribed in the MA- 12 
Extend Authorization use case. If callbacks still exist, the USER will be returned to Step 5 of the 
Basic Flow on completion of the MA- 12 Extend Authorization use case. 

If all callbacks have been completed, the Basic Flow continues. 

8. The system will display a screen to indicate that all repair facility callbacks for the office have 
been completed. 

9. This ends this use case. 
14.3 Alternative Flows 

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER 
feedback is provided. 

1.4.3. 1 Change Last Authorized Date 

At Step 3 or Step 5 of the Basic Flow, the USER has the ability to change the last authorized day 
to any day in the future. The system will re-generate the callbacks list and the USER will be 
returned to Step 2 of the Basic Flow on submission of the new last authorized day. 

1.4.3.2 Last Authorized Date Entered Invalid 

In the Change Last Authorized Date Alternative Flow, if the last authorized date entered by the 
USER is invalid, the system will return to the beginning of the Change Last Authorized Date 
Alternative Flow and provide the USER with an error message. 

1.4.3.2.1 It will be considered invalid if the last authorized date entered is less than the 
current date. 



1.5 Post-Conditions 

• If successful, a callback list is created for the USER. 
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• If unsuccessful, the system state re 



is unchanged. 



1 .6 Special Requirements 

1.7 Extension Points 

1.7.1 MA-12 Extend Authorization 

At Step 7 of the Basic Flow, the USER will extend from the use case to the MA-12 Extend Authorization 
use case. This will allow the USER to update the open authorization with the results of the repair facility 
callback (e.g., extend, add notes, or terminate the rental authorization). On completion of the MA-12 
Extend Authorization use case, the rules specified within the Basic Flow should be followed as to the next 
step in the process. 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

2.1 Repair Facility Callback Summary 

This screen provides the USER with a repair facility callback summary, and supports Step 3 of the Basic 
Flow. 



2.1.1 Screen Layout -^S-C^ ^\<jOf^ ^ 





/ 
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1 . Reject An Invoice Use Case 

1.1 Brief Description 

The Reject at? Invoice use case describes how the ADJUSTER would reject an invoice lo Enterprise ir 
the ARMS Web system. 

1.2 Use Case Actors / 

The following actors^will interact with this use case: 

• ADJUSTER - f he ADJUSTER will use this use case to reject an invoiei 

1.3 Pre-Conditions / 

• The ADJUSTER'S office must be set up for individual approval o/mvoices. 

• The ADJUSTER must be; set up to approve invoices. / 

1.4 Flow of Events \ / 

The Flow of Events will include the necessary steps for an ADJUSTER to reject invoices. 
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1)4.2 Basic Flow 

\ 1 . The ADJUSTER will reject an invoice. 
\ 2. The system will prompt for reject confirmation. 
\ 3. The ADJUSTER will enter a reject reason for rejecting the invoice. I 
\. The ADJUSTER may enter comments to be added to the diary notes 

5. \ The ADJUSTER will submit the rejection to the system. 

6. The system will display instructions for achieving resolution on the rejected invoice. 

7. The ADJUSTER will acknowledge that they understand the instructions. 

8. Tne system will update the ARMS Web database to reflect that the ADJUSTER rejected 
the invoice. 

9. This ends the use case. 

1.4.3 Alternative Flows 

1-4.3-\ Cancel Rejection 
At steps^wo through seven of the Basic Flow, theADJUSTER must have the ability 
to cancel \he invoice rejection process. Canceling the rejection should return the 
ADJUSTER, to the Invoicing Approval Screen^r the Invoicing Individual Payment 
screen. The'invoice that was to be rejected sj/ould be displayed. The status of the 
invoice shoul^be unapproved. / 

1.4.3.2 No Reject Reason Given / 

At step three in the,Basic Flow; if the ADJUSTER attempts to bypass entering a 
reject reason, they wall be prompted tb enter one. The ADJUSTER will not be 
allowed to complete the rejection process without providing a reject reason. 

1.4.3.3 Short Pay \ j 

If the reject reason given irkstep/ three of the Basic Flow is a reason that requires a 
short pay, at step five of the^aiic Flow the system will display a field for entry of 
the short pay amount. The ADJUSTER will not be allowed to complete the rejection 
process without providing an' amount that will be paid. 

1.5 Post-Conditions j \ 

• If the use case was successful the invj/ice will beta arked rejected in the ARMS Web system. 

• If the use case was unsuccessful, the/status remains unchanged. 

1.6 Special Requirements / \ 

The additional requirements of the business use case are\ncluded here. These are requirements not 
covered by the flow as they have bpen described in the settions above. 

1.6.1 Invoices are Initially /Kuto Approved \ 

If an ADJUSTER'S invoices/are normally auto approved, functionality needs to exist to route invoices 
to them when they are reti}rned to ADJUSTER from the PROCESSOR. This functionality will need to 
override the normal routing processes that exist at the office. 

1.7 Extension Points/ 

None. / \ 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used t^ implement the 
flows identified above. More than one screen may be used to implement support for the ijfse case flow. 

Reject Billing Reason 

This screen will allow the user to begin the rejection process. 
2.1.1 Screen Layout - Reject Billing Reason 



m_1 AeiSclSfcgPagel JiM 



Reject Billing 

Reject Billing 

You've chosen to reject the following invoice 
Adjuster's Kama Renter's Name Claim Number 

Reason for rejection: ^^^^^^^|] 



2.1.2 Reject Billing - Reject Billing Reason 















Amount 


Output 


10 


Total Amount Due 


/CALCULATE 1 *? 




Number 


Output 


15 


Claim Number , 


Insurance ClaimX 
Number \ 




Adjuster's 


Output 


30 


Adjuster's Name / 


First Name + Last \ 


Name of adjuster's to which the invoice 
is assigned 


Comments 




50 


Message Text / 


NOTE \ 




Renter's 
Name 


Output 


30 


Renter's name / 


First Name + Last \ 


Renter's Last Name + Renter's First 


Reason for 
Rejection 


List Box 


20 


Rejection Reasons 

/ 


standard message \ 
description \ 




/ 

/ 





/ 

2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be\performed within the screen. 
This includes op/rations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 
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/ 

2.1.3.1 CONTINUE j 

The system will validate the input from the screen according to the listed business rules. 

If the validation passes, the rejection process will continue. / 

The following business rules that must be passed before the USER may/continue to the 
next step in the rejection process are the following: / 

\ ■ A valid rejection reason must be selected from the drop down box 

> If the rejection reason selected is "Other" a comment mus/be entered 

2.1.3.k CANCEL j 
When clicked, the user will be returned to the Invoicing Approval or Invoicing 
Individuai\Payment screen. The invoice will still be displayed/with the status of the 
invoice unchanged. / 

/ 
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2.2 Reject Billing Amount 

2. 2. 1 Screen, Layout - Reject Billing Amount 



^ ^ ~ Reject Billing 

Reject Billing 

You've chosen to reject the following invoice. 
Adjuster's Name Renter's Name Claim Number 

Warner, Kurt Bamvakais, John 5698754821 

Amount you are paying: ISHHHHHHfljl 



To complete this process, please contact the 
rental branch location listed below: 
Enterprise Rent-A-Car 
600 New Haven Rd. 
Charlotte, NC 28210 
704-553-2001 



TT 















Claim Number 


Output 


15 


Claim Number 


Insurance Claim 

NjMfT 






Output 


15,2 


Invoice Amount 


^otal Amount Due 




Adjuster's Name 


Output 


30 


Adjuster's Name ^ 


^First Nine + Last 
Name \ 


Name of adjuster's to which the invoice 
is assigned 


Handling For 


Output 


30 


Handling for Adjuste^ 


First Nante + Last 
Name \ 


Adjuster's First name + Adjuster's last 
name. The name of the adjuster to which 
the invoice is currently assigned. 




Output 


30 


User's Name ^ 


First Name ^ Last 


Adjuster's last name + adjuster's first 
name. The name of the current adjuster 
in the system 




Output 


30 


Rental Location 
Address / 


Address Line ^ 
Address Line2 \ 






Output 


30 


Rental location City, 
State^and Zip 


City + State + Z\o 
Code \ 






Output 


15 


Repial Location 
"{telephone Number 


Telephone Numbe^ 
\ 
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Renter's Name 


Output 


30 


Renter's name 


First Name + Last 


Renter's Last Name f- Renter's First 
Name / 


To complete this 
process, please 
contact the 
Enterprise 
Branch listed 
below: 


Output 


50 


Rental Location 
Accounting Name 


accounting name 


/ 



2.2.3 Screen Function Definition I 

This section includes tl^e definitions for all functions that can be performed within the screen. 
This includes operations, invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. \ 

2.2.3.1 REJECT'JNVOICE / 

The system will validate the input from the screen. If the validation passes, the invoice 
will be marked as rejected and the Arms Web database will be updated. If an amount 
was entered in the "Amount you are paying" field, then the invoice should be marked 
short paid. \ / 



2.2.3.2 CANCEL \ j 

When clicked, the user will be,returned to the Invoicing Approval or Invoicing 
Individual Payment screen. THe invoice will s/ill be displayed with the status of the 
invoice unchanged. 
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3. Application Operations / 

This section will detail all the application operations that are part of this Functional ^Specification 
Document. / 

3.1 Get Invoice Rejection Reasons (Company Id) / 

The get invoice rejection reasons gets the predefined rejection reasons for the company. 

3.2 Reject Invoice (Invoice Number) / 

The reject invoice operation marks the specified invoice as rejected. The rejected invoice 
becomes an action item for the adjuster to handle. / 
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4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification 



4.1.1 accounting. name 



Entity 


OFFDRB OFFICE DIRECTORY BRANCH MASTER / 


Column Name 


acctgnam / 


Label Name 


Accounting Name / 


System Name 


' x / 


Data Type 


VARCllAR(8) / 


Attribute Definition 




4.1.2 Address Line \ j 


Entity 


ARM: Rentaf Location Master / 


Column Name 


LOADL1 \ / 


Label Name 




System Name 


1 


Data Type 


CHAR(30) \ / 


Attribute Definition 




/ 

4.1. 3 Address Line2 / 


Entity 


ARM: Rental Location Master / 


Column Name 


LOADL2 / 


Label Name 


Address Line / 


System Name 




Data Type 


CHAR(30) '. / 


Attribute Definition 




\ / 

4.1.4 City \ j 


Entity 


ARM: Rental Location Master \ / 


Column Name 


LOCYNM V 


Label Name 


City /\ 


System Name 




Data Type 


CHAR(20) / \ 


Attribute Definition 


/ \ 


/ \ 

4.1.5 external organization abbreviated name \ 


Entity 


EXTERNAL ORGANIZATION 


Column Name 


eoabbrnam / \ 


Label Name 


external organization abbreviated name: \ 


System Name 


EOABBRNAM / \ 


Data Type 


CHAR(10) / 


Attribute Definition 


External Organization Abbreviated Name is a shortened text based label 
associated with an organization outside of Enterprise. This name is 
sometimes used/tor accounting purposes. \ 
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4.1.6 First Name 



Entity 


ARM: Adjuster Master / 


Column Name 


ALFSNM / 


Label Name 


First Name / 


System Name 




Data Type 


CHAR(15) / 


Attribute Definition 




4.1.7 First Name J 


Entity 


ARM: Renter Detail / 


Column Name 


RKFSNM / 


Label Name 


First Name / 


System Name 




Data Type 


CHAR(t.?) / 


Attribute Definition 




4.1.8 Insurance Claim NumBer I 


Entity 


A4 Invoice Hejader / 


Column Name 


I1CLNO \ / 


Label Name 


Insurance ClaimlNumber / 


System Name 




Data Type 


CHAR(20) \ / 


Attribute Definition 




4.19 Last Name \ / 


Entity 


ARM: Adjuster Master / 


Column Name 


ALLSNM \ / 


Label Name 


Last Name Y 


System Name 




Data Type 


CHAR(20) / \ 


Attribute Definition 




4.1.10 Last Name / \ 


Entity 


ARM: Renter Detafl \ 


Column Name 


RKLSNM / \ 


Label Name 


Last Name / \ 


System Name 




Data Type 


CHAR(20) / \ 


Attribute Definition 




4.1.11 standard message description \ 


Entity 


STANDARD MESSAGE \ 


Column Name 


std_n/sg_dsc \ 


Label Name 


standard message description: \ 


System Name 


STi)MSGDSC \ 


Data Type 


C4lAR(50) \ 


Attribute Definition 


/the standard message description is a lexical definition for standard message 
' code which defines a predefined messag^ which is applicable to specific 
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activity type codes. For example: "Authorization confirmed orf &Date with 
Reservation Number &Resnumber" / 


4.172 State j 


Entity 


ARM: Rental Location Master / 


Column Name 


LOSACD / 


Label Name 


, State / 


System Name 




Data Type 


CHAR(2) / 


Attribute Definition 




4.1.13 Telephone Number I 


Entity 


ARM: Rental Location Master / 


Column Name 


LOPIINO / 


Label Name 


Telephone Number / 


System Name 




Data Type 


NUMERIC(IO) / 


Attribute Definition 




4.1.14 Total Amount Due \ / 


Entity 


A4 Invoice Trailer, / 


Column Name 


I3BL$$ \ / 


Label Name 


Total Amount Due \ / 


System Name 


\ / 


Data Type 


DECIMAL(9,2) \ 


Attribute Definition 




4.1.15 Zip Code \ 


Entity 


ARM: Rental Location Master/ 


Column Name 


LOZPCD \ / 


Label Name 


Zip Code y 


System Name 




Data Type 


CHAR(9) / \ 


Attribute Definition 
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Generate Personal Report 

1 . Generate Personal Report 

1.1 Brief Description 

This use case describes how a USER would generate a report on their personal rental management activity. 
Personal reports allow the USER access to reporting on only their own rental management activity, which 
allows the USER to review their own performance and secures access to the rental management reports of 
others. 

1.2 Use Case Actors 

All actors will use the use case to generate personal reports in the ARMS Web system. AH of the following 
actors can be defined generically as a USER: 

• ADJUSTER 

• PROCESSOR 

• COMPANY MANAGER 

For the balance of this use case, all of the above actors will be referred to as USER. 

1.3 Pre-Conditions 

• The USER must be signed-on to the system. 

1.4 Flow of Events 

The Flow of Events includes all the steps necessary to generate personal reports in the ARMS Web system. 
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1.4.2 Basic Flow 

The Basic Flow of the Generate Personal Report use case includes all of the required activities for the 
USER to successfully generate and view a standard personal report in ARMS Web. 

1 . The USER selects to generate a personal report from the top navigation bar. 

2. The system generates the report for the specific USER. The report should provide rental 
management reports for the signed-in USER. The default report view to display to the USER will 
be the Open Ticket Detail view (see section 1 .6.1 of the Special Requirements section on page 5 
for further definition). 

3. The system displays the report to the USER. 

4. This ends this use case. 

1.4.3 Alternative Flows 

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER 
feedback is provided. The Alternative Flows are optional and only occur if the conditions specified are 
met. 

1.4.3.1 Change Report View 

At Step 3 of the Basic Flow, the USER will have the ability to change the report 'view". Report 
'views' change the type of information that is presented to the USER, but maintains the same or 
similar scope. For example, the USER can select to change to a closed ticket detail view from the 
open ticket detail view, but the information presented is limited (scoped) to the rental management 
activity of the USER. 

If the USER selects to change the report view, the system will return to Step 2 of the Basic Flow 
and re-generate the report to build the requested view. 

14. 3.2 Change Closed Ticket Date Range 

At Step 3 of the Basic Flow, if the current report view is a closed ticket report, the USER will 
have the ability to change the date range of the report. The available date range for closed ticket 
reporting will be a rolling 13-month period (to be expanded to 24-months in future releases) with 
the current month inclusive. The default date range that will be presented to the USER will be the 
current and previous two (2) months. The USER will have the ability to select Month/Year to 
begin and end the date range for the closed ticket report. The USER will not have the ability to 
select specific days within a month as part of the date range. 

If the USER selects a new date range for the closed ticket report view, the system will return to 
Step 2 of the Basic Flow and re-generate the report to build the USERs closed ticket report for the 
selected date range. 

14.3.3 Select Open Ticket from Open Ticket Detail Report 

At Step 3 of the Basic Flow, if the current report view is an open ticket detail report, the USER 
will have the ability to select a report line item to view the details of the open ticket customer file. 
When selected, the system will present the USER with the customer file that corresponds to the 
selected open ticket. The USER will be allowed to modify and submit changes to the customer 
file (as proscribed in use case MA- 13 Change Authorization). Once activity on the customer file 
is complete, the USER should be returned to the open ticket detail report (Step 3 of the Basic 
Flow). 



Report views are covered in more detail in Section 1.6 Special Requirements. 
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1.4.3.4 Select Closed Ticket from Closed Ticket Detail Report 
At Step 3 of the Basic Flow, if the current report view is a closed ticket detail report, the USER 
will have the ability to select a report line item to view the details of the closed ticket customer 
file. When selected, the system will present the USER with the closed customer file that 
corresponds to the selected closed ticket. The USER will be allowed to view/print the details of 
the closed ticket, but will not have the ability to modify or change the ticket information. From 
the closed customer file, the USER will be returned to the closed ticket detail report (Step 3 of the 
Basic Flow). 

14.3.5 Sort Report 

At Step 3 of the Basic Flow, the USER will have the ability to select any report column heading 
to have the report sorted by the selected column. If the USER selects a column heading, the 
system must sort the report by the selected column heading in ascending order. The USER will 
have the ability to toggle between ascending and descending sort order by re-selecting the 
currently sorted column. For example, if the USER wanted their report view to be sorted by 
Renter Name, clicking on the column would cause the report view to be sorted ascending by renter 
last name. If the USER would like to reverse the sort order to descending , selecting the column 
heading again would allow the report to be resorted descending by renter last name. 

The system will return the USER to Step 3 of the Basic Flow on completion of this Alternative 
Flow, with the report view resorted according to the USER request. 

14.3.6 Add/Edit Custom View 

At Step 3 of the Basic Flow, the USER will have the ability to add or edit a custom report view. 
If the USER selects to add a report view, the system will extend to the RP-03 Add/Edit Custom 
View use case to define a new custom report layout. 

If the USER is viewing a custom report, they will have the ability to edit the custom view by 
selecting an 'edit' option. When a user requests to edit a custom report layout, the system will 
extend to the RP-03 Add/Edit Custom View use case and pre-fill all corresponding fields with the 
currently selected parameters for the custom layout. 

On completion of the use case extension, the USER will be returned to Step 2 of Basic Flow in 
this use case and be presented with the custom report layout that was defined/modified. 

1 4. 3. 7 Select Download Report 

At Step 3 of the Basic Flow, the USER will have the ability to download the current report view 
to a comma-delimited file. If the USER selects to download a comma-delimited version of the 
report, the system must publish a comma-delimited file that includes all of the data within the 
columns of the current report view. The comma-delimited file should include column headings 
for each of the columns of data provided to the USER. The comma-delimited file must also 
include report header information that includes: 

• Report View (open ticket detail/closed ticket detail) 

• Name of the Adjuster 

• Date and time the report was generated 

The system should return the USER to the report view (Step 3 of the Basic Flow) once a report 
has been successfully downloaded. 
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Post-Conditions 

• If successful, a standard report is created for the USER. 

• If unsuccessful, the system state remains unchanged. 



1.6 Special Requirements 

The special requirements for this use case define all of the personal report 'views' that are available to the 
USER. This list of personal report views may be expanded at a later date to include additional information 
from the ARMS/400 reporting detail files, but only these views are anticipated for the initial release. 

1.6.1 Open Ticket Detail View 

The Open Ticket Detail View provides the USER with columns of data on all currently open tickets under 
their management. The Open Ticket Detail report will display the following information to the user: 

1. Renter Name 

2. Claim Number 

3. Claim Type 

4. Authorized Rate* 

5. Authorized Days* 

6. Rental Days* 

7. Number of Days Behind* 

8 . Number of Extensions* 

9. Surcharges (Y/N) 

10. Authorized Amount* 

Specific rules that must apply to the Open Ticket Detail report view are outlined in the sections below; 

1.6.1.1 Data Columns in the Open Ticket Detail View should be presented in the order 
defined above. For example, renter name belongs in column 1 of the Open 
Ticket Detail report. 

1.6. 1.2 All numeric fields should have averages provided at the foot of each 
corresponding column. Numeric fields are indicated with an asterisk (*) in the list 
above. 

1.6.1.3 The default sort for the Open Ticket Detail view must be by the Number of Days 
Behind field, with open tickets that are the farthest behind presented at the top of 
the list. 

1.6.1.4 Any open tickets that have a value greater than zero (0) in the Number of Days 
Behind field should be highlighted to the USER. 

1.6.1.5 The report must include a count of the total number of contracts in the list. 

1.6.1.6 The report view must include report header information (in both screen and 
downloaded versions) that includes: 

• the type/view of report (open ticket detail) 

• the name of the USER for whom the report was generated 

• the date/time the open ticket report was generated 
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1. 6.2 Closed Ticket Detail View 

The Closed Ticket Detail View provides the USER with columns of data on closed ticket activity for the 
currently selected date range (the default date range is the current plus previous two (2) months). The 
Closed Ticket Detail report will display the following information to the user: 

1. Renter Name 

2. Claim Number 

3. Claim Type 

4. Authorized Rate* 

5. Authorized Days* 

6. Billed Days* 

7. Number of Extensions* 

8. Total Charges* 

9. Amount Received* 

10. Billed Amount* 

Specific rules that must apply to the Closed Ticket Detail report view are outlined in the sections below; 

1. 6.2. 1 Data Columns in the Closed Ticket Detail View should be presented in the order 
defined above. For example, renter name belongs in column 1 of the Closed 
Ticket Detail report. 

1.6.2.2 All numeric fields should have averages provided at the foot of each 
corresponding column. Numeric fields are indicated with an asterisk (*) in the list 
above. 

1.6.2.3 The default sort for the Closed Ticket Detail view must be by the Claim Number 
field. 

1.6.2.4 The report must include a count of the total number of contracts in the list. 

1. 6.2.5 The report view must include report header information (in both screen and 
downloaded versions) that includes: 

• the type/view of report view (closed ticket detail) 

• the name of the USER for whom the report was generated 

• the date/time the open ticket report was generated 

16.3 Custom Report Views 

The USER will have the ability to define their own custom report views through the RP-03 Add/Edit 
Custom View use case. These custom views are accessible from the Personal Reporting module of ARMS 
Web. 

1. 6.4 Report View Management 

The system will present all of the records in a report result set on a single page, and the USER will scroll 
through the results to find specific records. Report views will not be presented in paging format (e.g., 
forcing the USER to review the Next 25 of 427 records). 
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1.7 Extension Points 

This section describes the extension points of this use case. 

1. 7. 1 MA-13 Change Authorization 

If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the 
MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report 
Alternative Flow on page 3 for additional detail). The USER will have the ability to make any changes or 
updates that their security level allows, and have the opportunity to return to this use case without making 
any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, 
the USER will be returned to Step 3 of the Basic Flow within this use case (be presented with the Open' 
Ticket Detail report). 

1.7.2 RP-03 Add/Edit Custom View 

If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom 
View use case (see the Add/Edit Custom View Alternative Flow on page 4 for additional detail). The 
USER will define or modify their custom report layout and be returned to Step 2 of the Basic Flow within 
this use case. 



Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 

Personal Report Template Screen 

This screen provides the template to build personal report 'views', and supports Step 3 of the B 




Screen 
| Label 


Tvpe 


Length 


Data Field 


Screen Specific Rule 


Office 


Combo 
Box 




Branch 
claims office 


This combo list should include all of the offices 
for the currently active company that the USER 
is assigned to. 

If the value of this field is changed, the system 
should automatically refresh the screen with the 
current report view for the newly selected office. 


Handling 
for 


Output 
Text 




Handling for 


For personal reports, this value should always be 
'Yourself. 




Output 
Text 




<Report By> 


The <report by> field is a place holder in the 
header of the report view. For personal reports, 
this placeholder should be populated with the 
name of the user that is being reported on (i.e., 
the name of the user that requested the report). 
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1 Screen 
1 Label 


Type 


Length 


Data Field 


Screen Specific Rule 




Output 
Text 




<Tirne/Date 
Stamp> 


The <time/date stamp> field is a placeholder in 

reports, this placeholder should be populated 
with the date and time that the report was 
generated. 




Output 
Text 




<Report 
Type> 


The <report type> field is a placeholder in the 

this placeholder should be populated with the 
name of the current report view (e.g., Open 
Ticket Detail, Custom View 1) 


<Column 
Heading 
1 through 

X> 


Output 
Text 




<Data 
Columns 1 
through X> 


The data columns of the report should 
correspond to the data columns defined for the 
selected report view (either static or custom 
report view). The data columns should be 
presented in the sequence that they are defined. 


Total 


Output 
Text 




Number of 
Customer 
Files 


The total field should include the total number 
of contracts/customer files that are represented 
in the report. 


Select a 
view 


Combo 
Box 




Report view 
selection 


The 'select a view' combo box should include 
the names of all report views that are available 
to the user. This includes all pre-defined (e.g., 
Open Ticket Detail) and user-defined custom 
views. 

There should be an additional option to 'Add a 
custom view. . . '. If selected, the system should 
redirect the user to the Add/Edit Custom View 
screen in the RP-03 Add/Edit Custom View 
specification. 


Show 
Only 


Combo 
Box 




Claim Type 
Filter 


The 'show only' combo box should include the 
following values: 

• All Claim Types (default) 

• Insured Claim Types 

• Claimant Claim Types 

• Uninsured Claim Types 

• Theft Claim Types 

When selected, the report should filter the 
records to display in the requested report view 
according to the selection in this combo box. 
For example, if the selection in the 'show only' 
field were 'Insured Claim Types', the report 
view would only include records that have a 
Claim Type of 'Insured. | 
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Screen 
Label 


Type 


Length 


Data Field 


Screen Specific Rule 


From 


Combo 
box 




Closed ticket 
report from 
date 


The 'From' combo box should include all 
months and years for the last 13 months (rolling 
1 3 month period, current month inclusive). For 
example a value in this field might include 
'January 2000'. 

The default value should be ^monA^pngr to 
the current month. 


To 


Combo 
box 




Closed ticket 
report to date 


The 'From' combo box should include all 
months and years for the last 13 months (rolling 
13 month period, current month inclusive). For 
example a value in this field might include 'July 
2000'. 

The default value should be the current month. 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Choose a different report 

The 'Choose a different report' screen function provides the USER with a hyperlink to the View a 
Different Report section of the Personal Report Template screen. The 'Choose a different report' 
screen function must be at or near the header of the report. 

2.1.3.2 Go to Report A verages 

The 'Go to Report Averages' screen function provides the USER with a hyperlink to the bottom 
of the report to review the averages for each of the numeric columns in the report view. The 'Go 
to Report Averages' hyperlink must be at or near the header of the report. 

2. 13.3 Column Heading Sort 

The 'Column Heading Sort' screen function allows the USER to click on any column heading and 
have the current report view sorted by the selected column. On initial selection of a column 
heading, the system will resort the report view by the column selected in ascending order. If the 
sorted column is selected by the USER, the system will resort the report in descending order. 

2.1.3.4 Download this report 

The 'Download this Report' screen function allows the USER to click on a hyperlink and 
download a comma-delimited copy of the current report view. The downloaded copy must 
include: 

❖ Report Header Information 

> Name of the Report View 

> Name of the Person 

> Date and Time that the Report Was generated 

❖ Report View Column Headings 





❖ Report View Records 



2.13.5 View Report 

The 'View Report' screen function allows the USER to submit a request for a different type 
and/or date range of the report view. The system will refresh the screen with updated report view 
information when this screen function is invoked. 

2.13.6 Edit Custom View 

The Edit Custom View screen function is available only in cases that the USER has a custom 
defined view active. If the USER selects the Edit Custom View hyperlink, the system will 
present the USER with the Add/Edit Custom View screen and pre-populate the screen with the 
custom view definition. This will allow the USER to edit the custom views that they have 
previously defined. 
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Authorize Direct Bill : fo r Reed, 

CUSTOMER FILE 



Direct Bill Requested for: Claim Number: I 1 23-9829 

| l Hayo ^|Economy/18.99 g miggl 

Policy: Daily rate/| p|ease chose a rate . g 
Maximum dollars' Wm 

Direct Bill%: ll??J 

Vehicle Condition:) Please select a condition jjjj 

Date of Loss:| September g |20j|| |2000j|j gig 



Date Rental Needed: ! September 18 [22j| [2000 |§f Bp) 

Insured Name: Last:| | Firstf 

Messages: 
Go to Notebook 



J Claim Type: Ei^ZS 
Note to Enterprise: 



Note to Self Only: 



[Change or Add] 

RENTER INFORMATION; 

Keith Reed 



Home: (314)555-3876 
Work: Work: N/A 



RENTAL ilMFORiVIATJOPlI 

Enterprise Rent-A-Car Location: 

ENTERPRISE RENT-A-CAR 

3725 BOGEY RD 

SAINT CHARLES MO 633033105 

6369463010 

ADDITIONAIL CLAIM INFORM AT3 ON; 

Insured Name: N/A 
Owner's vehicle: N/A 
Date of Loss: 9/20/00 



Repair Facility: 

N/A 




\ / / 

http:/Nabpcad02/am^^ \ 10/20^00 



Claims Office: 003 



Handling for: Yourself 



Extend Rental: for Scott Clinton Claim no. 615-3456 

CUSTOMER PILE 



Ext ension requested for: 

[3 jadditional authorized days @ lCompact/20.99 |§fl 

Messages: 

Go to Notebook 



Note to Enterprise: 



Current Rental Status: 

Rental Start Date: 

Last authorized ending date: 

Authorized to date: 

Charges to Date: 

Direct Bill %: 

*Does not include taxes and surcharge 



9/22/00 
9/26/00 
4 

$83.96* 
100 



Rental Location: 

ENTERPRISE RENT-A-CAR 

(314)918-1300 

Repair Facility: 

Owner's vehicle: 

Vehicle Condition : Driveable 

n Extend this rent 



[Change or Add] 



RSItfTCR INFORMATSON; 

Scott, Clinton 

RBNTAt INFORMATION: 

Current Class: Compact 
Additional Charges: None 
Direct Bill %: 100 
Rental Date: 9/22/00 
Start Date: 9/21/00 

ADDITIONAL CLAIM INFQRIUiATIOf* 

Claim Number: 615-3456 
Claim Type: Claimant 
Insured Name: 
Owner's vehicle: 
Date of Loss: 9/21/00 
Type of Loss: Driveable 
Policy: Daily rate/ 
Maximum dollars: 



Home: (314)555-2345 
Work: N/A 
Email: N/A 

Enterprise Rent-A-Car Location: 

ENTERPRISE RENT-A-CAR 
2229 S BRENTWOOD BLVD 
SAINT LOUIS MO 631441832 
(314)918-1300 



Repair Facility: 



I '•IT- 



NOTEBOOK: 



Claims Office: 003 



Handling for: Yourself 



Persona i Reports : for <Report By> as of <Time/Date Stamp> 

<Report Type> 

Choose a different report 



[Click on the column heading to sort] 0 Go to Report Totals 



Renter Name Claim Number Claim Type 


Billed 


Authorized 


Number of 


Authorized 


Amount 


Days 


Days 




Rate 


Received 


Walker, L 12345678901234567890 Insured 


15 


13 


2 


20.00 


YES 


Oquendo. J 12345678901234567891 Insured 


13 


12 


1 


25.00 


YES 


Snffey Jr, 12 3 4 5 6 78901234567890 Claimant 


10 


13 


0 


16.99 


NO 


McGwire Jvl 12345678901234567892 Uninsured 


5 


12 


0 


19.99 


NO 


Lankford, R 12345678901234567891 Claimant 


7 


0 


0 


23.99 


YES 


Jordan, B 12345678901234567891 Claimant 


8 


15 


0 


21.99 


NO 


Totals 6 Customer Files Averages 


7.16 


13.33 


.33 


0.5 





* top of page 



'Excludes taxes and governmen 
Downlpa 



Choose a different report: 



Select a rr — — 

Open Ticket Summary 
uiaw l~ ' — 



For Closed Tickets, please select a time period: 



From: [January 2000 
To: J March 2000 
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1. Generate Management Report 

1.1 Brief Description 

This use case describes how a USER would request and generate management reports using the on-line 
reporting functionality of ARMS Web. On-line management reports provide real-time access to open and 
closed ticket information, which provides the management team of our customers with a tool to effectively 
monitor rental management statistics. Using the on-line reporting functionality, USERs can request and 
receive summarized and detailed rental management reports on their Office, on Adjusters within an office, 
or on the Repair Facilities that are trading partners of a particular office. 

NOTE: The on-line reporting functionality of ARMS Web provides ARMS ticket data only. ARMS and 
Non-ARMS reporting is available through the monthly L480 report. 

1.2 Use Case Actors 

All actors will use the use case to generate management reports in the ARMS Web system. All of the 
following actors can be defined generically as a USER: 

• ADJUSTER - Adjusters may be granted the authority to access management reports in their user 
profile 1 . 

• COMPANY MANAGER - All users that are identified to the system as managers will have 
access rights to the management reporting functionality. 

For the balance of this use case, all of the above actors will be referred to as USER. 

1.3 Pre-Conditions 

• The USER must be signed-on to the system. 

• The USER must have the authority to access management reports. 

1 .4 Flow of Events 

The Flow of Events includes all the steps necessary to generate management reports in the ARMS Web 
system. 



1 Users may be granted access to management reporting capabilities through their user profile, even if they are not considered 'managers' in the 
ARMS Web system. 





1.4.2 Basic Flow 

The Basic Flow of the Generate Management Report use case includes all of the required activities for the 
USER to successfully generate and view a management report using the on-line reporting functionality in 
ARMS Web. 



1 . The USER selects to generate a management report from top navigation. 

2. The system generates a Closed Ticket Summary report by Adjuster for the USER. Management 
reporting USERs will have the ability to request additional summary or detail reports for: 

a. The office as a whole (by Office) 

b. The adjusters within an office (by Adjuster) 

c. The repair facilities doing business with a claims office (by Repair Facility) 

3. The system displays the report to the USER. 

4. This ends this use case. 

14.3 Alternative Flows 

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER 
feedback is provided. 

1.4.3.1 Change Report View 

At Step 6 of the Basic Flow, the USER will have the ability to change the report 'view' 2 . Report 
'views' change the type of information that is presented to the USER, but maintains the same or 
similar scope. 

If the USER selects to change the report view, the system will return to Step 5 of the Basic Flow 
and re-generate the report to build the requested view. NOTE: The USER may also change the 
Report By criteria to request a new report view (e.g., request a report by Adjuster, Office, or 
Repair Facility). 

14.3.2 Change Closed Ticket Date Range 

At Step 6 of the Basic Flow, if the current report view is a closed ticket report, the USER will 
have the ability to change the date range of the report. The available date range for closed ticket 
reporting will be a rolling 13-month period (to be expanded to 24-months in future releases) with 
the current month inclusive. The default date range that will be presented to the USER will be the 
current and previous two (2) months. The USER will have the ability to select Month/Year to 
begin and end the date range for the closed ticket report. The USER will not have the ability to 
select specific days within a month as part of the date range. 

If the USER selects a new date range for the closed ticket report view, the system will return to 
Step 5 of the Basic Flow and re-generate the report to build the USERs closed ticket report for the 
selected date range. 

This applies to both summary and detail views of closed ticket reports. 




1.4.3.3 Select Summary Line Item from Open Ticket Summary Report 

At Step 6 of the Basic Flow, if the current report view is an open ticket summary report, the 
USER will have the ability to select a report line item, which will trigger a request for a more 
detailed report for the selected item. For example, if the current view were an Open Ticket 
Summary for Adjusters within an office (Open Summary by Adjuster), the USER would have the 
ability to select an adjuster from the summarized report and review the Open Ticket Detail report 
for that adjuster. This 'drill-down' capability must be available for all report types (by Office, by 
Adjuster, by Repair Facility). 

If the USER selects a line item from a summary report view, the system will return to Step 5 of 
the Basic Flow and generate the Open Ticket Detail report view for the selected item. From the 
Open Ticket Detail, the USER will have the ability to return to the Open Ticket Summary or to 
continue reviewing the Open Ticket Detail report views for each adjuster/repair facility within the 
office. 

1.4.3.4 Select Open Ticket from Open Ticket Detail Report 

At Step 6 of the Basic Flow, if the current report view is an open ticket detail report, the USER 
will have the ability to select a report line item to view the details of the open ticket customer file. 
When selected, the system will present the USER with the customer file that corresponds to the 
selected open ticket. The USER will be allowed to modify and submit changes to the customer 
file (as proscribed in use case MA-13 Change Authorization). Once activity on the customer file 
is complete, the USER should be returned to the open ticket detail report (Step 6 of the Basic 
Flow). 

1.4.3.5 Select Summary Line Item from Closed Ticket Summary Report 

At Step 6 of the Basic Flow, if the current report view is a closed ticket summary report, the 
USER will have the ability to select a report line item, which will trigger a request for a more 
detailed report for the selected item. For example, if the current view were a Closed Ticket 
Summary for Repair Facilities within an office (Closed Summary by Repair Facility), the USER 
would have the ability to select a repair facility name from the summarized report and review the 
Closed Ticket Detail report for that repair facility. This 'drill-down' capability must be available 
for all report types (by Office, by Adjuster, by Repair Facility). 

If the USER selects a line item from a summary report view, the system will return to Step 5 of 
the Basic Flow and generate the Closed Ticket Detail report view for the selected item. From the 
Closed Ticket Detail, the USER will have the ability to return to the Closed Ticket Summary or to 
continue reviewing the Closed Ticket Detail report views for each adjuster/repair facility within 
the office. 

14.3.6 Select Closed Ticket from Closed Ticket Detail Report 

At Step 6 of the Basic Flow, if the current report view is a closed ticket detail report, the USER 
will have the ability to select a report line item to view the details of the closed ticket customer 
file. When selected, the system will present the USER with the closed customer file that 
corresponds to the selected closed ticket. The USER will be allowed to view/print the details of 
the closed ticket, but will not have the ability to modify or change the ticket information. From 
the closed customer file, the USER will be returned to the closed ticket detail report (Step 6 of the 
Basic Flow). 

14.3.7 Sort Report 

At Step 6 of the Basic Flow, the USER will have the ability to select any report column heading 
to have the report sorted by the selected column. If the USER selects a column heading, the 
system must sort the report by the selected column heading in ascending order. The USER will 
have the ability to toggle between ascending and descending sort order by re-selecting the 
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currently sorted column. For example, if the USER wanted their report view to be sorted by 
Renter Name clicking on the column would cause the report view to be sorted ascending by renter 
last name. If the USER would like to reverse the sort order to descending, selecting the column 
heading again would allow the report to be resorted descending by renter last name. 
The system will return the USER to Step 6 of the Basic Flow on completion of this Alternative 
Flow, with the report view resorted according to the USER request. 

1.4.3.8 Add/Edit Custom View 

At Step 6 of the Basic Flow, the USER will have the ability to add or edit a custom report view. 
If the USER selects to add a report view, the system will extend to the RP-03 Add/Edit Custom 
View use case to define a new custom report layout. 

If the USER is viewing a custom report, they will have the ability to edit the custom view by 
selecting an 'edit' option. When a user requests to edit a custom report layout, the system will 
extend to the RP-03 Add/Edit Custom View use case and pre-fill all corresponding fields with the 
currently selected parameters for the custom layout. 

On completion of the use case extension, the USER will be returned to Step 5 of Basic Flow in 
this use case and be presented with the custom report layout that was defined/modified. 

1.4.3.9 Select Download Report 

At Step 6 of the Basic Flow, the USER will have the ability to download the current report view 
to a comma-delimited file. If the USER selects to download a comma-delimited version of the 
report, the system must publish a comma-delimited file that includes all of the data within the 
columns of the current report view. The comma-delimited file should include column headings 
for each of the columns of data provided to the USER. The comma-delimited file must also 
include report header information that includes: 

• Report View (open ticket detail/closed ticket detail) 

• Name of the Adjuster 

• Date and time the report was generated 

The system should return the USER to the report view (Step 6 of the Basic Flow) once a report 
has been successfully downloaded. 



1.5 Post-Conditions 

• If successful, a standard report is created for the USER. 

• If unsuccessful, the system state remains unchanged. 



1.6 Special Requirements 

The special requirements for this use case define all of the management report 'views' that are available to 
the USER. Management reports will be provided two USERs in two ways: 

• ' Standard' reporting views that have been defined by Enterprise at the request of customers 

• ' Custom' reporting detail views that allow the USER to define the columns of data that they 
would like to be present in a report 
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1.6.1 Standard Management Reporting Views 

Standard management reporting views are views that have been defined by Enterprise based on the 
requests of customers. These views will be carried forward in to ARMS Web and are defined in this 
section. (*e*-W<*e> E^*) 

The table below^ncludes the detailed data fields that are available on each of the 'standard' management 
reports. The columns available in each report have been expanded somewhat over the current state, as the 
web environment offers more flexibility to provide additional information than the current state green 
screen application. The sequence of columns that must be presented in each report are indicated using the 
number 1-10, with fields that are on the screen but not in the primary data table indicated with an 'X'. For 
example, the first column in the 'Adjuster - Open Detail' report is the renter name, the second column is 
the claim number, etc. 




1.6.1.1 All numeric fields should have averages provided at the foot of each 
corresponding column. Numeric fields are indicated with an asterisk (*) in the list 
above. 

1.6. 1.2 The default sort for the Open Ticket Detail views must be by the Number of Days 
Behind field, with open tickets that are the farthest behind presented at the top of 
the list. 

1.6. 1.3 The default sort for the Closed Ticket Detail views must be by Claim Number. 

1.6. 1.4 The default sort for the Open Ticket Summary views must be by Adjuster Name 
(if by Adjuster), Repair Facility Name (if by Repair Facility), or Office Name (if by 
Office) 



«Pdm2/ReadDocOrLink.ASP?Fol 



"'\~ Enterprise Rent-A^r©^^/ 



1.6. 1.5 The default sort for the Closed Ticket Summary views must be by Adjuster Name 
(if by Adjuster), Repair Facility Name (if by Repair Facility), or Month/Year (if by 
Office) 

1.6. 1.6 Any items in an Open Ticket Detail view that have a value greater than zero (0) in 
the Number of Days Behind field should be highlighted to the USER. 

1.6.1.7 All report views must include a count of the total number of contracts listed. 

1.6. 1.8 The report view must include report header information (in both screen and 
downloaded versions) that includes: 

• the type/name of the report view (e.g., open ticket detail, open ticket summary) 

• the name of the entity that is being reported on. For summary views, this should 
always be the office name. For detail views, the entity name must be: 

o the adjuster name (for reports by Adjuster) 

o the office name (for reports by Office) 

o the repair facility name (for reports by Repair Facility) 

• the date/time the report was generated 

1.6.2 Custom Management Reporting Views 

Custom management reporting views allow the USER to define the fields that they would like to use to 
build their own report. The fields selected by the USER become the columns of the report, and the system 
will not limit the number of columns that a USER can request as part of the report. Custom reporting 
views are discussed at length in use case RP-03 Add/Edit Custom View. 

1.6.3 Report View Management 

The system will present all of the records in a report result set on a single page, and the USER will scroll 
through the results to find specific records. Report views will not be presented in paging format (e.g., 
forcing the USER to review the Next 25 of 427 records). 

Extension Points 

This section describes the extension points of this use case. 

1.7.1 MA-13 Change Authorization 

If the USER selects a line item from the Open Ticket Detail report view, the USER will extend into the 
MA-13 Change Authorization use case (see the Select Open Ticket from Open Ticket Detail Report 
Alternative Flow on page 4 for additional detail). The USER will have the ability to make any changes or 
updates that their security level allows, and have the opportunity to return to this use case without making 
any changes to the open ticket. On completion of activity in the MA-13 Change Authorization use case, 
the USER will be returned to Step 6 of the Basic Flow within this use case. 

1. 7.2 RP-03 Add/Edit Custom View 

If the USER selects to add or edit a custom view, the USER will extend into the RP-03 Add/Edit Custom 
View use case (see the Add/Edit Custom View Alternative Flow on page 5 for additional detail). The 
USER will define or modify their custom report layout and be returned to Step 6 of the Basic Flow within 
this use case. 
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2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 Management Report View Template 

This screen provides the USER with a management report view template, and supports Step 6 of the Basic 
Flow. 



2.1.1 Screen Layout — 
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Automated Rpntal Management System 



Management Reports: for<ReportBy>asof 

<Report Type> 



View a different report: 



Select a view: | Open Ticket Summary jj 





Show Only: |AI 
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2.1.2 Screen Field Definition 






Label 


Type 


Length 


Data Field 


Screen Specific Rule j 


Office 


Combo 
Box 




Branch 
claims office 


This combo list should include all of the offices 
for the currently active company that the USER 
is assigned to. 

If the value of this field is changed, the system 
should automatically refresh the screen with the 
current report view for the newly selected office. 


Handling 
for 


Output 
Text 




Handling for 


For management reports, this value should 
always be 'Yourself. 



r 



r 




Output 
Text 



<ReportBy> 



The <report by> field is a placeholder in the 
header of the report view. For management 
reports, this placeholder should be populated 
with the name of the entity that is being reported 
(i.e., Adjuster Name, Office Name, or Repair 
Facility Name). 



Output 
Text 



<Time/Date 
Stamp> 



The <time/date stamp> field is a placeholder in 
the header of the report view. For management 
reports, this placeholder should be populated 
with the date and time that the report was 
generated. 



Output 
Text 



<Report 
Type> 



The <report type> field is a placeholder in the 
header of the report view. For management 
reports, this placeholder should be populated 
with the name of the current report view (e.g. 
Open Ticket Detail, Custom View 1) 



<Column 
Heading 
1 through 



Output 
Text 



<Data 
Columns 1 
through X> 



The data columns of the report should 
correspond to the data columns defined for the 
selected report view (either static or custom 
report view). The data columns should be 
presented in the sequence that they are defined. 



Output 
Text 



Number of 
Customer 
Files 



The total field should include the total number 
of contracts/customer files that are represented 
in the report. 



Combo 
Box 



Report sorted 
by navigation 



The 'Go to' combo box should include all of the 
entities available in the current report. For 
example, if the report were an Open Ticket 
Detail view Reported By Adjuster, this list 
would include all of the Adjusters that would 
PAGE in the list. 

The 'Go to' combo box should only be available 
in detail views. 



Report 
by 



Combo 
box 



Report sorted 
by 



The 'Report by' combo box should include al! 
of the currently available report by options in 
the ARMS Web system. The report by options 
for the initial release of ARMS Web 2.0 should 
be: 'Office', 'Adjuster', and 'Repair Facility 1 



Select a 
view 



Combo 
Box 



Report view 
selection 



The 'select a view' combo box should include 
the names of all report views that are available 
to the user. This includes all pre-defined (e.g. 
Open Ticket Detail) and user-defined custom 



There should be an additional option to 'Add a 
custom view...'. If selected, the system should 
redirect the user to the Add/Edit Custom View 
screen in the RP-03 Add/Edit Custom View 
specification. 
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Screen 
Label 


Type Length 


Data Field 




Show 
Only 


Combo 
Box 




Claim Type 
Filter 


The 'show only' combo box should include the 
following values: 

• All Claim Types (default) 

• Insured Claim Types 

• Claimant Claim Types 

• Uninsured Claim Types 

• Theft Claim Types 

When selected, the report should filter the 
records to display in the requested report view 
according to the selection in this combo box. 
For example, if the selection in the 'show only' 
field were 'Insured Claim Types', the report 
view would only include records that have a 
Claim Type of 'Insured. 


From 


Combo 
box 




Closed ticket 
report from 
date 


The 'From' combo box should include all 
months and years for the last 13 months (rolling 
13 month period, current month inclusive). For 
example a value in this field might include 
'January 2000'. 

The default value should be 2 months prior to 
the current month. 


To 


Combo 
box 




Closed ticket 
report to date 


The 'From' combo box should include all 
months and years for the last 13 months (rolling 
13 month period, current month inclusive). For 
example a value in this field might include 'July 
2000'. 

The default value should be the current month. 



2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 



2. 1.3. 1 Choose a different report 

The 'Choose a different report' screen function provides the USER with a hyperlink to the View a 
Different Report section of the Personal Report Template screen. The 'Choose a different report' 
screen function must be at or near the header of the report. 

2.1.3.2 Go to Report Averages 

The 'Go to Report Averages' screen function provides the USER with a hyperlink to the bottom 
of the report to review the averages for each of the numeric columns in the report view. The 'Go 
to Report Averages' hyperlink must be at or near the header of the report. 

2.1.3.3 Column Heading Sort 

The 'Column Heading Sort' screen function allows the USER to click on any column heading and 
have the current report view sorted by the selected column. On initial selection of a column 
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heading, the system will resort the report view by the column selected in ascending order If the 
sorted column is selected by the USER, the system will resort the report m descendmg order. 

2.1.3.4 Previous <Report By> 

The 'Previous <Report By>' screen function allows the USER to navigate to the previous ; detiul 
record in a particular detail report. For example, if the report view were an Open Ticket^ Detail 
report by Repair Facility, the 'Previous <ReportBy> screen function would allow theUSER to 
move to the previous Repair Facility detail record in a report. This screen function should only be 
available on open or closed ticket detail views (including custom views), and should only be 
available if a previous report by item exists (i.e., we wouldn't have a previous item if we were on 
the first item in the list). 

2.13.5 Next <Report By> 

The 'Next <Report By>' screen function allows the USER to navigate to the next detail record in 
a particular detail report. For example, if the report view were an Open Ticket Detail report by 
Adjuster, the 'Next <Report By> screen function would allow the USER to move forward to the 
next Adjuster's detail report view within the office. This screen function should only be available 
on open or closed ticket detail views (including custom views), and should only be available it a 
next report by item exists (i.e., we wouldn't have a next item if we were on the last item in the 
list). 



2.1.3.6 Download this report 

The 'Download this Report' screen function allows the USER to click on a hyperlink and 
download a comma-delimited copy of the current report view. The downloaded copy must 
include: 

❖ Report Header Information 

> Name of the Report View 

> Name of the Person 

> Date and Time that the Report Was generated 

❖ Report View Column Headings 

❖ Report View Records 



2.1.3.7 View Report 

The 'View Report' screen function allows the USER to submit a request for a different type 
and/or date range of the report view. The system will refresh the screen with updated report view 
information when this screen function is invoked. 



2. 1.3.8 Edit Custom View 

The Edit Custom View screen function is available only in cases that the USER has a custom 
defined view active. If the USER selects the Edit Custom View hyperlink, the system will 
present the USER with the Add/Edit Custom View screen and pre-populate the screen with the 
custom view definition. This will allow the USER to edit the custom views that they have 
previously defined. 
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ARMS Redesign Project - Release 2.0 

Add/Edit Custom View 

1 . Generate Management Report 

1 .1 Brief Description 

The Add/Edit Custom View use case describes the process to add or edit a custom report view in the 
ARMS Web system. Custom views allow the USER to select the data columns that they would like to 
view in a report (from a pre-defined list of available fields). USERs will have the ability to access their 
custom views just as they would any other 'standard' report view. 

1 .2 Use Case Actors 

All actors will use the use case to add or edit a custom report view(s) in the ARMS Web system. All of the 
following actors can be defined generically as a USER: 

• ADJUSTER 

• COMPANY MANAGER 

For the balance of this use case, all of the above actors will be referred to as USER. 

1.3 Pre-Conditions 

• The USER must be signed-on to the system. 

• The USER must have the on-line reporting functionality active (i.e., must be on an on-line reporting 
screen). 

1.4 Flow of Events 

The Flow of Events includes all the steps necessary to add or edit a custom report view in the ARMS Web 
system. 






\ 



14.2 Basic Flow 

The Basic Flow of the Add/Edit Custom View use case includes all of the required activities for the USER 
to successfully add or edit a custom report view for use in the on-line reporting functionality of ARMS 
Web. 

1 . The USER selects to add or edit a custom report view from the on-line reporting screen(s). 

2. The system displays a screen that allows the USER to define or build a custom report view. 

3. The USER defines the custom report view. The USER will have the ability to indicate a Name for 
the view, and define the data columns that they would like to have reported. The comprehensive 
list of data columns that will be available to the USER can be found in Section 1.6 Special 
Requirements (on page 4). 

4. The USER will submit the custom view to the system. 

5 . The system will update the ARMS Web database. 

6. This ends this use case. 

1.4.3 Alternative Flows 

The Alternative Flows of this use case can occur when certain conditions exist or when specific USER 
feedback is provided. 

1.4.3. 1 Edit Custom Report View 

At Step 1 of the Basic Flow, if the USER selected to edit a current custom report view, the system 
will present the screen to define/build a custom report and pre-fill all fields with the current report 
definition. For example, if the USER were editing their 'Massive' custom report view, 'Massive' 
would appear in the report name field and all of the data columns that were previously defined as 
the massive report would appear in the 'selected columns' portion of the screen. 



1.5 Post-Conditions 

• If successful, a custom report view is created for the USER. 

• If unsuccessful, the system state remains unchanged. 





1.(5 Special Requirements 

The special requirements for this use case define all of the management report 'views' that are available to 
the USER. Management reports will be provided two USERs in two ways: 

1.6.1 Custom Report Definition 

This section provides the system framework for custom report view definition in the ARMS Web system. 
These are additional requirements around functionality to allow USERs to define/build custom report 
views, and apply to the use case as a whole. 

1.6.1.1 USERs will have the ability to create one or more custom views. 

1.6. 1.2 USERs will be able to define custom report views for DETAIL views only (USERs 
will not have the ability to define custom summary views 1 ). 

1.6.1.3 USERs will have the ability to select custom report views by Office, by Adjuster, 
or by Repair Facility (similar to the standard management reports). 

1.6. 1.4 Custom report views will be limited to the data columns in the Custom Report 
View Data Domain (see 1.6.2 Custom Report View Data Domain) 

1.6.1.5 Custom report views must define if the report view retrieves Open, Closed, or All 
Ticket statuses. 

1.6. 1.6 All custom report views defined as 'closed ticket only' must allow the user to 
indicate a date range. The default date range for custom views will be the same 
as the default range for standard closed ticket reports (the current month plus two 
(2) prior months). 

1.6.1.7 When a custom report view has been defined, the name of the custom report 
view will become a selection from the USERs view list. For example, 
'MyCustomView' would be seen in the list with 'Open Ticket Detail', 'Closed Ticket 
Detail', etc.. 



Most of the numeric fields that can be summarized for USERs are already provided in the standard management report views. 





1.6.2 Custom Report View Data Domain 

The following is a list of all available data columns that a USER may select as part of a custom report 
view. The number of columns that a USER selects to make part of the custom report view is not limited, 
which allows the USER to select a subset or all of these data fields to be published in their report. 



Adjuster 


Claim Number 


Claim Type 


Office Name 


Renter Name 


State of Rental Location 


Authorized Days 


Authorized Rate 


Policy Daily Rate 


Days Behind 


Number of Extensions 


Policy Maximum Rate 


Rental Days 


Billed Days 


Billed to % 


Repair Facility Name 


Insured Name 


Rental Status 


Total Charges 


Billed Amount 


Amount Received 


Other Charges 


Vehicle Condition (Driveable 
Flag/Repairable Flag) 


Authorized Total Amount 


Surcharges Flag 


Rental Start Date 


Rental Close Date 


Termination Date 


Invoice Date 


Invoice Approved Date 


Remittance Date 


Repair Facility Phone Number 





1.7 Extension Points 

None. 




Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 Add/Edit Custom View 

This screen provides the USER with the ability to add or edit a custom view, and supports Step 2 of the 
Basic Flow. 

2.1.1 Screen Layout - f \ njf t, t ^ ^0 \ 




Sa!«ct fialds to display on report 



Add th« fields yeu'd tike and the order 



New Report Fields 



Renter Name 
Claim Number 
Clam Type 
Billed Days 



Numeer of Extensions 
Total Charges 
Renter Charges 
Total BKKt Charges 



Other Charges 
Repair Facility 

ilDays 
Renter State 
Office 

Rental Open Date 
Rental Close Oats 






2.1.2 Screen Field Definition 



Label 


Type 


Length 


Data Field 


Screen Specific Rule I 


Name 
this 


Text 




Custom 
Report Name 


The name a USER provides to refer to the 
custom report view definition. 

The name of the report must be unique to other 
custom reports defined by the user (e.g., a single 
user can not have two reports with the same 
name). This uniqueness must only be enforced 
at the user level (e.g., two different users CAN 
use the same name for a report). 

The name of the report will appear in the USERs 
'Select a view' combo box when the report view 
is saved. 


Start 
from a 
View 


Combo 
box 




Custom view 
start point 


The 'Start from a View* combo list allows a 
USER to select a default or 'standard' view as a 
starting point in report view definition. The 
values within the combo box should be 'Open 
Ticket Detail' and 'Closed Ticket Detail'. If 
selected, the system should use the values of the 
Report by 'Adjuster' standard report to pre- 
populate the 'New Report Fields' list box.. 

The default value of this field should be '-Select 
a Starting View-' 


Ticket 
Status 


Combo 
box 




Custom view 
ticket status 


The 'Ticket Status' combo box indicates the 
scope of the report in terms of ticket status. The 
list should include 'Open Tickets', 'Closed 
Tickets', and 'All Tickets'. The system will use 
this as part of the overall custom report 
definition. 


Available 
Fields 


List Box 




Custom view 

available 

fields 


The 'Available Fields' list box includes all of 
the fields that are available to be included in a 
custom view, but have not yet been selected to 
be included in the report. 

When an available field is selected from the list 
to be included in the report, the field should be 
removed from this list box (and populate the 
'New Report Fields' list box). 

For a list of all available fields see Section 1.6.2 
Custom Report View Data Domain above. 




Label 


Type 


Length 


Data Field 


Screen Specific Rule 1 


New 

Report 

Fields 


List Box 




Custom view 

selected 

fields 


The 'New Report Fields list box includes all ot 
the fields that have been selected by the USER. 
These fields define the columns of the report. 

The sequence that the fields appear in the report 
is defined from top to bottom of this list box 
(e.g., the first field in the list = the first column 
in the report). This sequence can be modified 
using the Sequence Up and Sequence Down 
screen functions (see 0 
Screen Function Definition below). 

If the USER selects a starting view (from the 
Start from a View field), the list box will 
populate with all of the fields that make up the 
standard view selected (e.g., if the USER selects 
'Closed Ticket Detail' from the Start from a 
View field, all of the fields that make up a 
Closed Ticket Detail report would populate in 
this field. 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Remove 

The 'Remove' screen function allows a USER to remove selected fields from the 'New Report 
Fields' list box (and re-add them to the 'Available Fields' list box). 

2.1.3.2 Insert 

The 'Insert' screen function allows a USER to add selected fields to the 'New Report Fields' list 
box (and remove them from the 'Available Fields' list box). 

2.1.3.3 Dictionary 

The 'Dictionary' screen function allows a USER to open a dictionary that defines all of the fields 
that can be added to a report view. The dictionary will be included as part of the help 
functionality of the system. 

2.13.4 Sequence Up 

The 'Sequence Up' screen function (presented with an 'up' arrow in the screen shot) allows a 
USER to move a selected field in the 'New Report Fields' list box up in the sequence of the 
report. 

2.1.3.5 Sequence Down 

The 'Sequence Down' screen function (presented with a 'down' arrow in the screen shot) allows a 
USER to move a selected field in the 'New Report Fields' list box down in the sequence of the 
report. 
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2.1.3.6 Save Report View 

The 'Save Report View' screen function allows the USER to save the custom report definition and 
return to the reporting use case(s). The system will return the USER to the report use case from 
which they entered this use case (either RP-01 or RP-02) and be presented with the newly defined 
report view. 

2.1.3.7 Close without Saving 

The 'Close without Saving' screen function allows the USER to exist the screen with saving any 
changes made. The system will return the USER to the report use case from which they entered 
this use case (either RP-01 or RP-02). 

2.1.3.8 Delete 

The 'Delete' screen function allows the USER to delete a custom report view from their profile. 
When a custom report view is deleted it should no linger be available in the USERs view selection 
combo box. The system will return the USER to the report use case from which they entered this 
use case (either RP-01 or RP-02). 
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Maintain User 

Maintain User Use Case 

1.1 Brief Description 

The Maintain User use case describes how a USER would set up or maintain a user in the ARMS Web 
system. 

1 .2 Use Case Actors 

The following actors will interact with this use case: 

• ENTERPRISE ADMINISTRATOR - The ENTERPRISE ADMINISTRATOR is a person who 
can perform this use case to set up any user in a company. 

• COMPANY ADMINISTRATOR - The COMPANY ADMINISTRATOR is a person who can 
perform this use case for the company. They may add users and assign them to office(s) that they 
are the administrator of within the company. 

• OFFICE ADMINISTRATOR - The OFFICE ADMINISTRATOR is a person who can perform 
this use case for the company. The OFFICE ADMINISTRATOR may maintain any user in their 
company structure to which they have been assigned ownership. 

1.3 Pre-Conditions 

• The USER must be logged into the system. 

• If maintaining a user, the USER should have the ability to maintain that user. In order to maintain a 
user at a specific office, the ADMINISTRATOR must have access to that specific office. 

• If adding a user, the USER should have the ability to add a user. 

1.4 Flow of Events 

The Flow of Events will include all the steps necessary to add or maintain a company user in the ARMS 
Web system. 
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1.4.2 Basic Flow 

The Basic Flow will describe how a USER will maintain a user in the ARMS Web system. 

1 . The USER will choose to maintain user(s). 

2. The system will present a list of all users that are in all the offices the USER has access to 
maintain. 

3 . The USER will choose a user to maintain. 

4. The system will display the user's information for the USER to edit. 

5. The USER will update the user's information and submit the information to the system. 

6. The system will validate the information entered. 

7. The system will update the ARMS Web database. 

8 . This ends the use case. 

14.3 Alternative Flows 

1.4.3.1 Add User 

At step three in the Basic Flow, the USER may choose to add a user, if they have the authority 
level to do so. The USER will enter a primary office, UserlD, First Name and Last Name for the 
new user. The system will then validate that the office was entered and the UserlD does not exist. 
If a UserlD match is found, or the office was not entered, the system will display an error and 
request the USER enter a new UserlD. Otherwise, the system will display the default settings for 
a new user, the USER will update the default settings and submit the information to the system. 
The system will validate the information entered, and update the ARMS Web database. The use 
case is then complete. 

14.3.2 Show All Users for the Company 
At step three in the Basic Flow, the USER may choose to display all users within the company. 
This would allow for adding users to offices the USER controls. The USER will choose the user 
they wish to work with and the system will then display the user's information; the USER will add 
the user to any offices the USER controls and submit the information to the system. The system 
will validate the information entered, and update the ARMS Web database. The use case is then 
complete. 




1 .4.3.2. 1 If a user's primary office is not an office controlled by the USER, the USER may only 
add the user to offices the USER controls. The USER should not be able to change any 
of the user's settings. A USER that has control of a user's primary office can only 
change user settings. 

1.4.3.3 User Information Validation Fails 
In step six of the Basic Flow, the system may find that user information entered by the USER does 
not meet the validation criteria. The system should return the USER to step four of the Basic 
Flow, show the USER the invalid data, and prompt the USER to reenter the data. 

This rule also applies for new user creation. Whenever a new user is submitted to the system for 
creation, the system must validate that the criteria entered is valid. If any information is invalid, 
the system should present the invalid date to the USER, and prompt the user to correct it. 

1.4.3.3.1 The following fields must be populated to complete a user update or new user creation. 

• Last Name 

• First Name 

• UserlD (Must be validated to ensure it is not a duplicate ID) 

• Home Office (Must be a valid office and not null) 



14.3.4 Cancel Add I Maintain User 
Until step five in the Basic Flow, the USER may choose to cancel the use case. The system 
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should not store any changes made by the USER within the use case. 

1.5 Post-Conditions 

. If the use case was successful and the USER was maintaining a user, the user criteria being 
changed will have been changed and updated in the ARMS Web system. 

. If the use case was successful and the USER was adding a user, the user will have been added 
in the ARMS Web system. 

• If the use case was unsuccessful, the system state will be unchanged. 

1.6 Special Requirements 

1.6.1 User Inactivation 

In order to inactivate a user, the following set of criteria must be validated. If any of the criteria 
are found to be true, then the system will not allow the USER to inactivate the user. 
. If A4XREFL1/X4STCD is equal to 'C (closed rental) and any tickets were closed in the past 
seven days 

• If A4XREFL1/X4STCD is equal to 'A' (audited invoice) 

• If A4XREFL1/X4STCD is equal to 'R' (reservation) 

• If A4XREFL1/X4STCD is equal to 'O' (open contract) 

• If A4XREFL1/X4STCD is equal to 'U' (unconfirmed) and A4XREFL1/X4RSFG is equal to 
'D' (Direct Bill request) 

• If A4XREFL 1 /X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'C 
(extension request & message sent) 

. If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL 1 /X4RSFG is equal to 'M' 
(authorization message sent) 

• If A4XREFL1/X4STCD is equal to 'Z' (sent) and A4XREFL1/X4RSFG is equal to 'X' 
(extension request sent) 

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL 1 /X4RSFG is 
equal to 'B' (invoice sent from ARMS) 

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is 
equal to 'R' (invoice returned to adjuster) 

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL 1 /X4RSFG is 
equal to 'E' (rejected system error) 

• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL 1 /X4RSFG is 
equal to 'Q' (rejected invoice ARMS researching) 

1.6.2 User Default Settings 

Whenever a new user is created, the settings for that user should be defaulted based on the user's 
primary office profile settings. For example, if the office is a reservation only office, the user 
should default to reservation only. This does not imply that the administrator cannot change the 
settings. This should also apply to whether can receive work setting should be on or off for the 
user/team. If all other users/teams in the office have the setting either on or off, then the new user 
should mimic this setting. Once again, this does not imply that the administrator cannot change 
this setting. 



1.7 Extension Points 

None. 



2. Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that are used to 
implement the flows identified above. More than one screen may be used to implement support 
for the use case flow. 
2.1 Create or Modify User 

This screen will allow the USER to search for and select a user to modify or select to add a new 
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2. 1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. 

2.1.3.1 A-Z Anchor Links 

When any of the letters are clicked, the list of users should position itself with 
that letter presented at the top of the user view area on the page. 

2.1.3.2 Teams Link 

When the team link is clicked, the list of teams should position itself at the top 
of the view area on the page. The list of teams should be placed last in the list of 
all users/teams. 

2.1.3.3 Process 

When the Process button is clicked, the system should check to see that the 
appropriate information was entered in order to create a new user (Office, Last 
Name, First Name UserlD). If the information is entered, the system will create 
a new user with those attributes and the other user attributes defaulted. The 
system should then display the new user's profile. 



2.2 Create or Modify Team 

This screen will allow the USER to input and change information about a user (i.e. name, E-mail 
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2.2.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. 



2.2.3.1 A - Z Anchor Links 

When any of the letters are clicked, the list of users should position itself with 
that letter presented at the top of the user view area on the page. 

2.2.3.2 Teams Link 

When the team link is clicked, the list of teams should position itself at the top 
of the view area on the page. The list of teams should be placed last in the list of 
all users/teams. 

2.2.3.3 Process 

When the Process button is clicked, the system should check to see that the 
appropriate information was entered in order to create a new team (Office, Team 
Name). If the information is entered, the system will create a new team with 
those attributes and the other user attributes defaulted. The system should then 
display the new team's profile. 



2.3 User Profile 

This screen will allow the USER to input and change information about a user (i.e. name, E-mail 
address, etc.) 

2.3. 1 Screen Layout - <J&^ *"1 j VT€^ 1 » ^5 
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2.3.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. 
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2.3.3.1 Process 

When clicked, the system will ensure that all rules on the page are enforced. 
Upon completion, the system will return the USER to the Create a New User / 
Team page. 

2.3.3.1.1 The user must have a First Name, Last Name and Home Office entered. The 
Home Office must be a valid office for that company. 

2.3.3.1 .2 Work Authority for each user will default to all enabled. 

2 3 3 1 3 If the Active switch has been set to inactive, the system will check to see if the 
user owns any open work. If the user owns work, the system will not allow the user to be 
set to inactive. The system will notify the USER that the user has open work assigned to 
them and request that they transfer the work before attempting to inactivate the user. 



2.3.3.1.4 If the reset password option is set, the system will reset the user's 
This will reset the user's password to the password used for new users. Need to verify 
what that password is. 

2 3.3.1.5 If the File Ownership flag is turned off, the system will check to see if the user 
owns any open work. If the user owns work, the system will not allow the file ownership 
flag to be turned off. The system will notify the USER that the user has open work 
assigned to them and request that they transfer the work before attempting to turn off file 
ownership. 
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2.4.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. 

2.4.3.1 Process 

When clicked, the system will ensure that all rules on the page are enforced. 
Upon completion, the system will return the USER to the Create a New User / 
Team page. 

2.4.3.1 .1 The team must have a Team Name and Home Office entered. The Home 
Office must be a valid office for that company. 

2.4.3. 1 .2 If the Active switch has been set to inactive, the system will check to see if the 
team owns any open work. If the team owns work, the system will not allow the team to 
be set to inactive. The system will notify the USER that the team has open work assigned 
to them and request that they transfer the work before attempting to inactivate the team. 



2.4.3.1.3 If the File Ownership flag is turned off, the system will check to see if the team 




owns any open work. If the team owns work, the system will not allow the file 
ownership flag to be turned off. The system will notify the USER that the team has open 
work assigned to them and request that they transfer the work before attempting to turn 
off file ownership. If the user or team does not receive File Ownership, that user or team 
will not display in the Handle For list. 




Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document. 

3.1 Build list of Users 

(Office Id, First Name, Last Name, User ID) 

Build a list of User first and last names NOT limited to a given office in order to search for a user. 
Limited by the first or last name passed. 

3.2 Find User Information 

(User Id) 

Retrieve the current values for a user's profile. 

3.3 Update User Information 

(User Id, Name, e-mail Address, Out of Office, Handler for out of office user, Initial Page, Is 
user Multi-company, Is User Active, Current Password, New Password, Receive 
Authorization Assignment) 
Update the given data values for the user profile. 

3.4 Build list of User offices 
(User Id) 

Build a list of office names for the offices the user is assigned to. 

3.5 Find User Office Information 
(User Id, Office Id) 

Retrieve the current values assigned for the user at a given office. 

3.6 Update User Office Information 
(User Id, Office Id, and data values) 

Update the given data values for the user profile. 

3.7 Add User Office Information 

(User Id, Office Id) 

Assign user access to another office. Default values are set for the users access. 

3.8 Remove User Office Information 
(User Id, Office Id) 

Revoke assignment of the user to an office. The user cannot be revoked from their primary office 

3.9 Build a list of users to which the administrator has access 
(Company ID, Administrator ID, User ID) 

Build a list of User first and last names limited to a given office in order to maintain a user. 
Limited by the first or last name passed. 

3.10 Validate that User ID does not exist 
(User ID) 

Verify that the administartor must add a new user. 



Data Fields 
4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional 
specification. 

4.1.1 User Language Preference 

This is the user's language preference while working with the ARMS Web System. 

Data Field Type: Alpha-Numeric 

Data Field Length: 10 

Data Source: <Data Source> 

4.1.2 Phone Number 

This is the user's phone number. 

Data Field Type: Alpha-Numeric 

Data Field Length: 10 

Data Source: <Data Source> 

4.13 Profile Attribute Id 

I.S. assigned identifier for a profile attribute. Must be unique and non-blank. Each 
profilable item will have a profile attribute. 

Data Field Type: Alpha-Numeric 

Data Field Length: 20 

Data Source: <Data Source> 

4.1.4 Last Name 

This is the last name of the user. 

Data Field Type: Alpha-Numeric 

Data Field Length: 20 

Data Source: <Data Source> 



Handler for out of office user 

This is the user who will handle work for the user who is 



Data Field Type: 
Data Field Length: 
Data Source: 



Alpha-Numeric 
0 

<Data Source> 



Start Page 

This is the initial page that the user will see when he logs on to the system. 

Data Field Type: URL 
Data Field Length: 256 
Data Source: <Data Source> 




4.1.7 Is user out of office? 

This flag indicates that the user is out of office and no work should be assigned to them. 
Instead another user can be set up to handle for the user who is out of office. 

Data Field Type: Boolean 

Data Field Length: 1 

Data Source: <Data Source> 



4. 1.8 Is the user multicompany ? 

This flag indicates that this user can do work for multiple insurance companies. These 
are typically Enterprise Rent-A-Car employees working on site at an insurance company 
office or Rental Management Services employees who are also Enterprise employees 
who manage rentals for the insurance company but are not on site. 

Data Field Type: Boolean 

Data Field Length: 1 

Data Source: <Data Source> 



Can user receive work ? 

This flag indicates that user can receive work (e.g. requests for authorization, requests for 
extension etc.). Typically, a manager would set this flag to "No" so that work would not 
be assigned to him or her although he or she could be notified in certain situations like 
authority limit exceeded etc.. 

Data Field Type: Boolean 

Data Field Length: 1 

Data Source: <Data Source> 



4.1.10 Is User Active ? 

This flag indicates the user is currently active and may log on to the system to do work. 

Data Field Type: Boolean 

Data Field Length: 1 

Data Source: <Data Source> 



4.1.11 Email Address 

This is the email address of the user. 

Data Field Type: Alpha-Numeric 

Data Field Length: 30 

Data Source: <Data Source> 



4.1.12 First Name 

This is the first name of the user. 

Data Field Type: Alpha-Numeric 

Data Field Length: 15 

Data Source: <Data Source> 
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4.1.13 Password 

This is the user specified password that the user will use along with the user id to log on 
to the ARMS Web System. 

Data Field Type: Password 

Data Field Length: 10 

Data Source: <Data Source> 



4.1.14 User Id 

This is the user id that the user will use to sign on to the ARMS Web System. This id 
must be unique across the whole system. 



Data Field Type: Alpha-Numeric 

Data Field Length: 10 

Data Source: <Data Source> 





5. Questions and Answers 



Issue Number: 321 



Question: When do we "Kill" profiles that have been created but not used? 
Question 2 - Do we allow for deleting users, and if so, who would handle this 
function? Question 3 - Do we allow for deleting inactive user, and if so, who 
would handle this function? 



Status: Closed - Resolved 



Resolution: 3-21-00, Dave Smith - The other questions would seem to have 
procedures in place today. Unless there is a compelling reason, I don't think we 
should reinvent the wheel. Could you check with the ARMS team to find out? 
08-07-00 - Brad Reel: UserlDs that were created, but never accessed will be 
made inactive after six months. UserlDs that have not been accessed for two 
years will also be made inactive. After being made inactive, they will be purged 
after three additional months. 



Issue Number: 322 



Question: Do we allow for deleting users, and if so who would it be that does 
so? 



Status: Closed - Merged 



Resolution: 3-21-00, Dave Smith - The other questions would seem to have 
procedures in place today. Unless there is a compelling reason, I don't think we 
should reinvent the wheel. Could you check with the ARMS team to find out? 3- 
27-00, merged with Issue 321 



Issue Number: 323 




Question: When do we delete an inactive user? And who would handle? 



Status: Closed - Merged 



Resolution: 3-21-00, Dave Smith - The other questions would seem to have 
procedures in place today. Unless there is a compelling reason, I don't think we 
should reinvent the wheel. Could you check with the ARMS team to find out?3- 
27-00, merged with issue 321 



Issue Number: 324 



Question: User ID: Do we have current Enterprise Business rules that we need 
to enforce, and if so, what are they? The assumption we made when discussing 
this was that the admin could give them whatever ID the user desired. If user 
wanted the ID Beavis, the admin could create it. The question is, are there some 
rules we want to enforce (i.e. User ID'S start w/ first three characters of insurance 
company's name, GEI for GEICO) and some defaults for both UserlD & 
Password? Maybe for GEICO, the first user is GEI0001 and the default 
password is GEICO. Just something we need to address. 



Status: Closed - Resolved 



Resolution: 3-22-00, Dave Smith - 1 think we should give them whatever user ID 
they want. 

3- 30-00. Kim DeVallance - user ID is a company specific item. For example, 
GEICO's is their associate ID (similar to our employee number). Progressive 
uses their PACMAN ID, Nationwide uses their RACF ID.. .all a similar concept. It 
is an ID that the adjuster is familiar with and I think we should allow the customer 
to use an employee number already familiar to the adjuster. 

4- 7-00, Issue Mtg, the field is 1 0 characters, First three will be company driven, 
the next 7 can be alpha/num and the users choice. 

4-11-00, Brad Reel - Current State, ID's are first three characters of the 
company's name, and up to seven numeric characters. Could possibly expand to 
seven alpha-numeric instead of just numeric. Barring any disagreement, we will 
suggest the following in the ARMS Web system: first three characters of the 
company's name are the first three characters of the ID. Then the ID must 
include at least 4 alpha-numeric characters with at least one number in it. The 
minimum ID length would be 7 characters, the maximum 10. Suggest we try to 
force companies to use their employee IDs as the seven digits. ARMS Web 
system can generate a number if necessary. 




^_^_Jsgue:1.2 
IssueDate: Kj7SQ/00 ; 



Need to confirm with our security people that this is acceptable security on an 
Enterprise-owned application. Also, should consider whether or not we think first 
three chracters of a company's name will allow us to always uniquely identify 
companies. 



Issue Number: 325 



Question: Current State we capture the primary address for the user, (the 
address the user (adjuster) is located at) do we want to do the same in future 
state? In the screen prototype should the primary user (adjuster) address be 
capture in the user profile screens, given that we currently have an office address 
in the office profile? 



Status: Closed - Resolved 



Resolution: 3-30-00, Kim DeVallance - Kim-I do not think it is necessary for the 
ARMS/Web application, but it may be a mandatory field for the ARMS system 
when it processes info. I would recommend checking with the analysts from 
ARMS. We pull the address from ECARS when we send a paper bill, and if the 
bill is electronic, the address does not matter. 

4-7-00, Issue Mtg, Default to office address, allow at the user level to be 
changed, if it is changed it will only update the database not the 400. 
4-11-00, Brad Reel - When creating a user, we need to capture a user-specific 
address. It should default to the primary office they are assigned to when they 
are first created, but be changeable. This means we have to change the process 
for adding a user so we identify their primary office before we enter address 
information. 



Issue Number: 326 



Question: Can a user be maintained at more than one office? Do we still have a 
default/primary office when the user is created? 

Example: You have been created at the St. Louis Office and you need to travel to 
California to help with a disaster, does California have the rights to maintain you. 




Status: Closed - Resolved 



Resolution: 3-22-00, Dave Smith - For tracking purposes, I think we need to 
maintain one profile only. If someone moves to another location because of a 
disaster, we should move the profile to that office. Perhaps to make it easy on 
the transition, we could transfer their base profile and let the new office modify 
accordingly. 

3-27-00, Ask Brad to follow-up with Dave Smith. 

3-30-00, Kim DeVallance - Current state, yes a user can be maintained at more 
than one office, but a user should have a primary office. 



Issue Number: 327 



Question: Do we need a primary office at which you see all work below you? 
This would apply only to people who were in offices that were not claims offices. 
Example: I am a regional VP (wouldn't that be cool) and I want to use the 
system. I define "Default One" as my region, so when I look at stuff in the 
system an I see all the offices under my office as my default. 



Status: Closed - Resolved 



Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement. 
3-30-00, Kim DeVallance - This would be great!!! 



Issue Number: 328 



Question: Do we need a primary office that you can create work at? This would 
apply to everyone and defines the primary office I can create work in. For an 
Adjuster, this would be their primary office. For someone at a higher level, it 
would be the office they assign work to if they create it. Following the example 
above, if that VP creates a res (unlikely, but work with me), this default would be 
the claims office it would be sent to for completion. 




Status: Closed - Resolved 



IsslieJ>ate: 100/00 



Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement as well. 
3-30-00, Kim DeVallance - Yes, but keep in mind during the life of a rental we 
can transfer the rental to different offices within the same company profile. 



Issue Number: 329 



Question: Where does the manager get assigned to a user? At the Office Level, 
the User Level or the Team level? Can a user have more than one manager? 



Status: Closed - Resolved 



Resolution: 08-08-00 - Brad Reel: Upon further discussion with the business, 
the process for selecting a person to handle an authorization limit is as follows: 
When a user hits an authorization limit, the system will request that the user 
select another user to approve the request and handle the rental. The system 
will only present users that have limits higher than the requested amount/number 
of days. Once the user has been selected, the rental will then be permanently 
transferred to the chosen user. 



Issue Number: 331 



Question: Under Report Layout section, is this for the office to give the user 
what fields that they want them to see? Then the user can set how he views 
these fields in MY PROFILE? 



Status: Closed - Resolved 



Resolution: 3-21-00, Anita Klopfenstein - It allows the user to create a default 
report layout as well as establish groupings. For example: I may want a team 
group which allows me to select adjusters to view. However, this would be a 
function which had to be approved in the profile of the user. Otherwise they can 





Issue Number: 332 

Question: Are the authorization limits for the life of the rental or the transaction, 
(as applied to use by an adjuster) 

Status: Closed - Resolved 

Resolution: 3-21-00, Anita Klopfenstein - Both - There is a daily limit and a 
rental max. 

For the life of the rental. 



Issue Number: 350 

Question: Do we want to force a search before and admin can add a user? 
Status: Closed - Resolved 

Resolution: 08-07-00 - Brad Reel: When adding a user, the system will search 
for the UserlD and ensure it does not exist. No other searches will be performed. 



Issue Number: 352 




Question: Where does the ability to change the lang 
screens in reside? With the Admin or the user? 


uage the user can view the 





Status: Deferred 
Resolution: 



Issue Number: 356 

Question: When setting up a user, should the office profile restrict the user's 
profile? Or are the office and user profiles independant of each other? 

Status: Closed - Resolved 

Resolution: 08-07-00 - Brad Reel: Office profile overrides user profile. A user 
can have more rights than the office, but will still be restricted to only activities 
that can be performed in that office based on the office profile while they are 
working in that office. 



Issue Number: 360 

Question: Brad Decoder, Password/ do we send e-mail to the admin to let them 
know how many times login failed? 

Status: 12 User Review 

Resolution: 



Issue Number: 365 



J 




\ r , ^ — / — v — lsspe:4,2 

\„ jVlajntaifritseiy^ ""^^^ X ^.^- X "~'' - . / ' Issue Patey 10/20/0^ — 

Question: Do we need a batch process for adding users? 



Status: Closed - Resolved 



Resolution: 07-03-00 - Brad Reel: This question has also been asked in the 
more general setting of "Should a process exist for walking a user through setting 
up an entire company (much like a wizard tool)." For this release of ARMS Web 
(V2.0) a batch process for creating users will not be created. There will also not 
be a wizard for creating a company. However, for future releases, this wizard will 
be a very worthwhile tool to create and should be incorporated into future 
releases. 
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14.2 
The 



Basi,c Flow j 
Basic'f low will describe how a USER will maintain a user in the ARMS Web system. / 

1 . \The USER will choose to maintain user(s). / 

2. The system will present a list of all users that are in all the offices the US] 
maintain. 

3 . The^JSER will choose a user to maintain. 

4. The system will display the user's information for the USER to edit. 

5. The USER will update the user's information and submit the information to the system. 

6. The system will validate the information entered. 

7. The systerfo will update the ARMS Web database. 

8. This ends trite use case. 

1.4.3 Alternative Flows 

1.4.3.1 AddOser 

At step three in the BaVc Flow, the USER may choose to add a user, i/they have the authority 
level to do so. The USER will enter a primary office, UserlD, First Name and Last Name for the 
new user. The system wi)K then validate that the office was entered did the UserlD does not exist. 
If a UserlD match is founder the office was not entered, the systeni will display an error and 
request the USER enter a neV UserlD. Otherwise, the system wil/display the default settings for 
a new user; the USER will update the default settings and submit the information to the system. 
The system will validate the information entered, and update thfe ARMS Web database. The use 
case is then complete. 

1.4.3.2 Show All Users for\he Company 
At step three in the Basic Flow, the USER may choose to/display all users within the company 
This would allow for adding users to offices the USER /ontrols. The USER will choose the use 
they wish to work with and the system Vill then displa/ the user's information; the USER will au u 
the user to any offices the USER control\ and submit /he information to the system The system 
will validate the information entered, and^pdate the ARMS Web database. The use case is then 
complete. s ; 



1 -4.3.2. 1 If a user's primary office is not an kfice controlled by the USER, the USER may only 
add the user to offices the USER coMols. The USER should not be able to change any 
of the user's settings. A USER that As control of a user's primary office can only 
change user settings. ' x 

1.4.3.3 User Information Validation /Fails 
In step six of the Basic Flow, the system may find tak user information entered by the USER does 
not meet the validation criteria. The system should relurn the USER to step four of the Basic 
Flow, show the USER the invalid data, ahd prompt the\USER to reenter the data. 

This rule also applies for new user creation. WheneveAnew user is submitted to the system for 
creation, the system must validate th/t the criteria entered is valid. If any information is invalid 
the system should present the inval/& date to the USER, and prompt the user to correct it. 

1.4.3.3. 1 The following fields ^uist be populated to compete a user update or new user creation. 

• LastNah 

• First Name 
UserlD (Must be validated to ensure it isWt a duplicate ID) 
Home Office (Must be a valid office and npt null) 

1.4.3.4 Cancel Add J Maintain User 
Until step five in the^asic Flow, the USER may choose to cancel uje use case. The system 
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Maintain User 

should not store any changes made by the USER within the use case. 

1.5 Post-Cotnditions 

• Ifvthe use case was successful and the USER was maintaining a user, the A 
changed will have been changed and updated in the ARMS Web systen/ 

• If th&use case was successful and the USER was adding a user, the u^er will have been added 
in the VRMS Web system. 

• If the us\ case was unsuccessful, the system state will be unchang^i 

1.6 Special Requirements 

1.6.1 User Inactivation \ 

In order to inactivate a user, the following set of criteria must be validated. If any of the criteria 
are found to be true,\then the system will not allow the USER to/nactivate the u: 

• If A4XREFL1/X4§TCD is equal to 'C (closed rental) and/any tickets were closed in the p; 
seven days 



If A4XREFL1/X4STCD is equal to 'A' (audited invoic 



If A4XREFL1/X4STCD is equal 'B' (auth< 
equal to 'E' (rejected system erro; 




If A4XREFL1/X4STCIJ is equal to 'R' (reservation) 
If A4XREFL1/X4STCD\s equal to 'O' (open contract) 

If A4XREFL1/X4STCD is'^qual to 'U' (unconfirmed) and A4XREFL 1 /X4RSFG is equal to 
'D' (Direct Bill request) \ / 

If A4XREFL1/X4STCD is eq\al to 'Z' (sent) 
(extension request & message stent) 

If A4XREFL1/X4STCD is equal to 'Z' (sent/and A4XREFL 1 /X4RSFG is equal to 'M' 
(authorization message sent) \ 

If A4XREFL1/X4STCD is equal to^ 
(extension request sent) 

If A4XREFL1/X4STCD is equal to 'B '^authorized invoice) and A4XREFL 1 /X4RSFG is 
equal to 'B' (invoice sent from ARMS) ' 

If A4XREFL1/X4STCD is equal to 'p' (authorized invoice) and A4XREFL 1 /X4RSFG is 
equal to 'R' (invoice returned to adjuster) 



invoice) and A4XREFL1/X4RSFG is 



• If A4XREFL1/X4STCD is equal to 'B' (authorized invoice) and A4XREFL1/X4RSFG is 
equal to 'Q' (rejected invoice ARMS researching^ 

User Default Settings I \ 

Whenever a new user is created/ the settings for that useAshould be defaulted based on the user's 
primary office profile settings/For example, if the officers a reservation only office, the user 
should default to reservation y6nly. This does not imply thkt the administrator cannot change the 
settings. This should also Wply to whether can receive woVk setting should be on or off for the 
user/team. If all other usenS/teams in the office have the setting either on or off, then the new user 
should mimic this setting/ Once again, this does not imply t^at the administrator cannot change 



T Extension Points 

None. 
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Screen Design 

A definition of the screen layout(s), screen data fields, and screen functions that ai 
implement the flows identified above. More than one screen may be used to impl 
for the use case flow. 

1 Create or Modify User 

This screen will allow the USER t 



search for and select a user to modify o 



2.1.1 Screen Layout 




Maintain User 



Issue Date/ 10/20/00 



Screen Label 


Type 


Siz 
e 


Screen Field Name 


Data Field Name 


Screen Specific Rule 


User ID 


Output 


10 


List of User Ids within 


Adjuster Code 




Name 


Output 


30 


List of Users within a 
Company 


First Name + Last 
Name 










User Id 


Adjuster Code 




Primary 
office 


List Box 


25 


Primary office 


external 

organization name 




Primary 


Output 


10 


List of Primary offices 


external 
organization 
abbreviated name 




Office 
Description 


Output 


20 


List of Office 
Descriptions within 
Company 


external 

organization name 




Office: 


Output 


4 


Office ld\ 


external 
organization 
abbreviated name 





2.1.3 Screen Function Definition 

This section includes the definitions for all functions that cantfe performed within the 
screen. This includes operations, invoked by button clicks, specific shortcut keystrokes 
or other actor activity. \ 

2.1.3.1 A- Z Anchor Links, 
When any of the letters are^plicked, the list of/fjsers should position itself with 
that letter presented at the top of the user view area on the p 

2.1.3.2 Teams Link 
When the team link is clicked, the list ol/teams should position itself at the top 
of the view area on the page. The list of teams should be placed last in the list of 
all users/teams. / 

2.1.3.3 Process Y 

When the Process button is clicked; the system should check to see that the 
appropriate information was entered unorder to create a new user (Office, Last 
Name, First Name UserlD). If the information is entered, the system will create 

v user with those attribute/ and the dther user attributes defaulted. The 
system should then display the new user's profile. 
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Issueyi 

Issue Date: 10C0/0O 



Screen Label 


Type 


Siz 


Screen Field Name 


Data Field Name 


Screen Specific Rule 


Email Address: 






Address 






First Name 


Text Box \ 


15 


First Name 


First Name 




Handling For 


Output \^ 


10 


Handling For 


First Name + Last 
Name 




Last Name 


Text Box 




Last Name 


Last Name 




User ID: 


Output 




User Id 


Adjustor Code 




Active 


Check Box 


\ 


User is Active 


StatusrActive/lnacti 
ve 




Address 


Output 


25\ 


Home Office Address 


Customer Address 
Line 1+ Customer 
Address Line 2 




Phone: 


Output 


10 


y Home Office Phone 
\Number 


Customer Phone 
Number + 
Customer Phone 
Extension 




Postal 


Output 


10 


H&me Office Postal 
Cc^e 


Zip Code 




City 


Output 


15 


Hoi^e Office City 


customer city text 




ST/PROV 


Output 


5 


Hom^Office State 


customer state 
code 




Office 


Output 


10 


Office 1 ^ 
\ 


external 
organization 
abbreviated name 




Home Office 


List Box 


20 


Office Name 
\ 


external j 
organization name/ 




Other authorized 
Offices 


List Box 


20 


Other authorized 
Offices for^he User 


external / 
organization nanrte 




action items to be 
assigned to this 


Check Box 


-j 


items to be assigned 
to user \ 


profile type value 
code / 

/ 


If Allow Files and Action Items have 
been selected, this user or team 
will appear in the Handle For list. 


Authorize/Extend 
Rental 


Check Box 


1 


Allow user to \ 
Authorize/Extend^ 
Rental \ 


profile type value 
code / 




User Maintence 


Check Box 


1 


Allow user to conduct 
user maintenance \ 


profit type value 
cods' 




Create Reservation 


Check Box 


1 


Allow user to create \ 
reservation \ 


profile type value 




Reporting 
(Management) 


Check Box 


1 


Allow user to do \ 
reporting \ 


pn5file type value 
code 




Pay Invoice 


Check Box 


1 


Allow user to Pay 
Invoices t 


Vprofile type value 
\;ode 




Days/Rental 


Text Box 


10 


Authorization Limit on/ 
Days per Rental / 


profile type value 
quantity 




$ max/rental 


Text Box 


10 


Authorization LimitAn 
Maxmimum Dollats 
per Rental / 


profile type value 
amount 





2.3.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoked by button clicks, specific shortcut keystrokes, 
or other actor activity. / \ 
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2.3.3.1 Process 

When clicked, the system will ensure that all rules on the page are enforced. 
Upon completion, the system will return the USER to the Create a New User / 
Team page. 




2.3.3. l.U The user must have a First Name, Last Name and Home Office entered. ' 
Home Office must be a valid office for that company. 

\ 

2.3.3.1.2 'Work Authority for each user will default to all enabled. 

2.3.3. 1 .3 If\the Active switch has been set to inactive, the system will check fc6 see if the 
user owns any open work. If the user owns work, the system will not allow die user to be 
set to inactiveA. The system will notify the USER that the user has open worlt assigned to 
them and requek that they transfer the work before attempting to inactivate/the user. 



2.3.3.1.4 Iftheri 
This will reset the user's 
what that password 



2.3.3.1.5 If the File Ownership flag is turned off, the system will check to see if the user 
owns any open work. If the user owns work, the system will not al/ow the file ownership 
flag to be turned off. The system will notify the USER that the usfer has open work 
assigned to them and reduest that they transfer the work before attempting to turn off file 
ownership. 




d option is set, the system will reset the user's password, 
d to the password used for new users. Need to verify 
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2.4.2 Cnkste 





Type 


Siz 
e 


Screen Field Name 


Data Field Name 


Screen Specific Rule ■ 


Allow files and 
ction items to be 
assigned to this 


\ 




be assigned to team 




J 


Available 


List Box \ 


30 

V 


Available Members 
for Team 


First Name + Last 
Name 


T 


E-mail Address 


Text Box 


*20 


Email Address 


e-Mail address 


/ 


Handling For: 


Output 


W 


Handling For 


First Name + Last 
Name 






Check Box 




Team Active Indicator 


Status:Active/lnacti 
ve 


— / 


Team Members 


List Box 


30 


.Team Members 


First Name + Last 
Name 


/ 


Phone Number 


Output 


10 


Branch Office Phone 
Number 


Customer Phone 
Number + 
Customer Phone 
Extension 


/ 


Postal 


Output 


10 


Branch Office Postal 
Code, 


Zip Code 


1 


Address 


Output 


25 


Home\Office Address 


Customer Address 
Line 1 + Customer 
Address Line 2 




STYPROV 


Output 


3 


Branch Office State 
or Provinee 


customer state 
code 


I 


City 


Output 


15 


Home Office City 


customer city text 




Home Office 


Output 


20 


Home Office Name 


external / 
organization nam/ 




Office 


Output 


5 


Office \ 


external / 
organization / 
abbreviated name 




Team Name 


Text Box 


20 


Team Name \ 


external / 
organizatiqn name 





/ 

2.4.3 Screen Function Definition \ / 

This section includes the definitions for all functions that can be performed within the 
screen. This includes operations invoBed by hdtton clicks, specific shortcut keystrokes 
or other actor activity. 

2.4.3.1 Process 

When clicked, the system will ejteure that all rules on the page are enforced. 
Upon completion, the system jvil^return the USER to the Create a New User / 
Team page. 

2.4.3.1. 1 The team must have a Team Nam& and Home Office entered. The Home 
Office must be a valid office fonfnat company. 

2.4.3.1.2 If the Active switcft has been set to inactive, the system will check to see if the 
team owns any open work/if the team owns wArk, the system will not allow the team to 
be set to inactive. The system will notify the USER that the team has open work assigned 
to them and request that they transfer the work before attempting to inactivate the team. 

2.4.3. 1 .3 If the Fil/Ownership flag is turned off, the system will check to see if the team 
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Issue: 1 
Issue Date: IO/71 

Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document 

3.1 Build list of Users 

(Office Id, First Name, Last Name, User ID) 

Build a list of User first and last names NOT limited to a given office in order to search/ 
Limited by the first or last name passed. 

Find User Information 

(User Id) 

Retrieve the current ^ 



alues for a 
Update User Information 



r's profile. 




(User Id, Name, e-mail Address, Out of Office, Handler for out of office nser, Initial Page, Is 
user Multi-company, Is CJser Active, Current Password, New Password/Receive 
Authorization Assignment) 

Update the given data values\for the user profile. 

Build list of User offn 

(User Id) 

Build a list of office names for th^ offices the user is assigned to. 

3.5 Find User Office information 
(User Id, Office Id) \ 

Retrieve the current values assigned for the user at a given office. 

3.6 Update User Office Information 
(User Id, Office Id, and data values) \ 

Update the given data values for the user profile. 

3.7 Add User Office Information \ 
(User Id, Office Id) \ 

Assign user access to another office. Defaulfevalue/ are set for the users a< 

3.8 Remove User Office Information 
(User Id, Office Id) 

Revoke assignment of the user to an office. The user cannot be revoked from their primary office 

3.9 Build a list of users to which the administrator has access 
(Company ID, Administrator ID, User ID) 

Build a list of User first and last names limited to a gWen office in order to maintain a user. 
Limited by the first or last 

Validate that User ID does not. exist 
(User ID) 

Verify that the administartor must arid a new user. 
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ie Date:/ 0/20/00 



4.17 ys user out of office ? 

This flag indicates that the user is out of office and no work should be assigned to tr 
\ Instead another user can be set up to handle for the user who is out of office. 

Data Field Type: Boolean 
Data Field Length: 1 
Data Source: <Data Source> 

4.1.8 Is the user multicompany ? 

This flag indicates that this user can do work for multiple insurance companies. These 
are typically Enterprise Rent-A-Car employees working on site at an insurance company 
office or Rental Management Services employees who are also Enterprise employees 
who manage rentals for the insurance company but are not on site. 

Data Field Type: Boolean 
Data Field Length: 1 
Data Source: \ <Data Source> 

Can user receive work ? \ 

This flag indicates that user can receive work (e.g. requests for authorization, requests for 
extension etc.). Typically! a manager would set this flag to "No/so that work would not 
be assigned to him or her although he or she could be notified jfa certain situations like 
authority limit exceeded etc.\ 

Data Field Type: Boolean 
Data Field Length: 1 
Data Source: <Data Source> 



4.1.10 Is User Active ? 

This flag indicates the user is currently active and rfiay log on to the system to do work. 

Data Field Type: Boolean \ 
Data Field Length: 1 
Data Source: <Data Sou\ce>/ 

4.1.11 Email Address 
This is the email address of the user. 

Data Field Type: Alpha-NuirJeric\ 
Data Field Length: 30 
Data Source: <Data S/urce> 

4.1.12 First Name 
This is the first name of the use] 

Data Field Type: Alpha-Numeric 
Data Field Length: A 5 
Data Source: / <Data Source> 
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5. Questions and Answers 




lssu<£ 1.2 
Issue Date: JW20/00 



Question: When do we "Kill" profiles that have been created but not usfed? 
Question\2 - Do we allow for deleting users, and if so, who would handle this 
function? Question 3 - Do we allow for deleting inactive user, and if s^, who 
would hanole this function? 

\ 



is: Closed - F 



Resolution: 3-21\00, Dave Smith - The other questions would/seem to have 
procedures in place^ today. Unless there is a compelling reasc/h, I don't think we 
should reinvent the "wheel. Could you check with the ARMS team to find out? 
08-07-00 - Brad Ree^ UserlDs that were created, but nevetfaccessed will be 
made inactive after siH months. UserlDs that have not befn accessed for two 
years will also be made, inactive. After being made inactive, they will be purged 
after three additional months. 




Issue Date: A 0/20/00 



Question: When do we delete an inactive user? And who would handle? 



Status: Closed - Merged 



Resolution: B-21 -00, Dave Smith - The other questions would seem to have 
procedures in jsrtace today. Unless there is a compelling reason, I dory think we 
should reinvent the wheel. Could you check with the ARMS team to |ind out?3- 
27-00, merged wHh issue 321 



issue Number: 324 



Question: User ID: Do we havfe current Enterprise Business rules that we need 
to enforce, and if so, what are tntey? The assumption we made when discussing 
this was that the admin could give\them whatever ID the user desired. If user 
wanted the ID Beavis, the admin cVild create it. Thefquestion is, are there some 
rules we want to enforce (i.e. User ID's start w/ first/three characters of insurance 
company's name, GEI for GEICO) arid some defaults for both UserlD & 
Password? Maybe for GEICO, the first user is GEI0001 and the default 
password is GEICO. Just something we need tp address. 



Status: Closed - Resolved 



Ihould give them whatever user ID 



Resolution: 3-22-00, Dave Smith - 1 think jt/e 
they want. 

3- 30-00. Kim DeVallance - user ID is a company specific item. For example, 
GEICO's is their associate ID (similar to/bur employee number). Progressive 
uses their PACMAN ID, Nationwide usefe their RACfF ID...all a similar concept. It 
is an ID that the adjuster is familiar with and I think we should allow the customer 
to use an employee number already familiar to the adjuster. 

4- 7-00, Issue Mtg, the field is 10 characters, First threft will be company driven, 
the next 7 can be alpha/num and tbfe users choice. 
4-1 1-00, Brad Reel - Current State, ID's are first three characters of the 
company's name, and up to seveVi numeric characters. Could possibly expand to 
seven alpha-numeric instead cfjust numeric. Barring any, disagreement, we will 
suggest the following in the ARMS Web system: first three\ characters of the 
company's name are the firs/ three characters of the ID. Then the ID must 
include at least 4 alpha-nupneric characters with at least one number in it. The 
minimum ID length would'toe 7 characters, the maximum lOASuggest we try to 
force companies to use/tfieir employee IDs as the seven digits. ARMS Web 
system can generate^ number if necessary. 



T 
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Maintain User 



Need'tp confirm with our security people that this is acceptable security on an 
Enterprise-owned application. Also, should consider whether or not we think f/rst 
three chracters of a company's name will allow us to always uniquely identify/ 
companies 



Issue Number: 325* 



Question: Current Statawe capture the primary address for the user, (the 
address the user (adjusted is located at) do we want to do thie same in future 
state? In the screen prototype should the primary user (adjuster) address be 
capture in the user profile screens, given that we currently h^ve an office address 
in the office profile? 



Status: Closed - Resolved 



Resolution: 3-30-00, Kim DeVallancte - Kim-I do no/ think it is necessary for the 
ARMS/Web application, but it may be^a mandatory/field for the ARMS system 
when it processes info. I would recommend checking with the analysts from 
ARMS. We pull the address from ECARS when/We send a paper bill, and if the 
bill is electronic, the address does not matter. 

4-7-00, Issue Mtg, Default to office address, ajfow at the user level to be 
changed, if it is changed it will only update\th£ database not the 400. 
4-1 1-00, Brad Reel - When creating a userVwe need to capture a user-specific 
address. It should default to the primary opce they are assigned to when they 
are first created, but be changeable. This' means we have to change the process 
for adding a user so we identify their primary suffice before we enter address 
information. 



Issue Number: 326 



Question: Can a user be/naintained at more than ^ne office? Do we still have a 
default/primary office when the user is created? 
Example: You have been created at the St. Louis Office and you need to travel to 
California to help with a disaster, does California have the rights to maintain you. 
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Issue> 1 .2 
Issue Date: 10720/00 



States: Closed - Resolved 

\ 

Resolution: 3-22-00, Dave Smith - For tracking purposes, I think we need/o 
maintain one profile only. If someone moves to another location because of a 
disaster, w4 should move the profile to that office. Perhaps to make it eas^y on 
the transition\we could transfer their base profile and let the new office/tiodify 
accordingly. \ 

3-27-00, Ask Bnad to follow-up with Dave Smith. 

3-30-00, Kim Demilance - Current state, yes a user can be maintai/ed at more 
than one office, but a user should have a primary office. 



Issue Number: 327 



Question: Do we need a primWy office at which you see all work below you? 
This would apply only to people\who were in offices ttiat were not claims offices 
Example: I am a regional VP (wbuldn't that be cool/and I want to use the 
system. I define "Default One" ak my region, so when I look at stuff in the 
system an I see all the offices u 



s undfer my office as/my default. 



Status: Closed - Resolved 



Resolution: 3-22-00, Dave Smith - Yes\/think this a good enhancement 
3-30-00, Kim DeVallance - This would b& great!!! 




Issue Number: 328 



Question: Do we need a primary office that you clan create work at? This would 
apply to everyone and defines the primary office I can create work in. For an 
Adjuster, this would be their/primary office. For sonteone at a higher level, it 
would be the office they assign work to if they create it. Following the example 
above, if that VP creates ?i res (unlikely, but work with me), this default would be 
the claims office it would-be sent to for completion. 
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Status: Closed - Resolved 



Resolution: 3-22-00, Dave Smith - Yes, I think this a good enhancement als well. 
3-30-00, Kim DeVallance - Yes, but keep in mind during the life of a renta/we 
can transferee rental to different offices within the same company profili 



Question: Where does the manager get assigned to a user? At the Office Level, 
the User Level or the TeaVi level? Can a user have more than o/e manager? 

Status: Closed - Resolved 



Resolution: 08-08-00 - Brad Refel: Upon further discussiofi with the business, 
the process for selecting a persorV to handle an authorizajtfon limit is as follows: 
When a user hits an authorization limit, the system will request that the user 
select another user to approve the request and handle/fie rental. The system 
will only present users that have limits higher than the/requested amount/number 
of days. Once the user has been selected, the rental will then be permanently 
transferred to the chosen user. \ 



Issue Number: 331 



Question: Under Report Layout section, is this for the office to give the user 
what fields that they want them to se/? Then theViser can set how he views 
these fields in MY PROFILE? 



Status: Closed - Resolved 



Resolution: 3-21-00, AnitsrKlopfenstein - It allows thd user to create a default 
report layout as well as establish groupings. For example: I may want a team 
group which allows me/ra select adjusters to view. However, this would be a 
function which had tpybe approved in the profile of the User. Otherwise they can 
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onto see their work. 



Issue Number: 332 



Question: Are thfe authorization limits for the life of the rental or/he transaction, 
(as applied to use\by an adjuster) 



Status: Closed - Resblved 



Resolution: 3-21-00, Anila Klopfenstein - Both - There i/ a daily limit and a 
rental max. \ ' 

For the life of the rental. \ 



Issue Number: 350 

Question: Do we want to force a search before and admin can add a user? 
Status: Closed - Resolved 

Resolution: 08-07-00 - Brad Reel: ytaen adding a user, the system will search 
for the UserlD and ensure it does raft exist. Ndother searches will be performed. 



Issue Number: 352 



Question: Where d( 
screens in reside? V 



the ability to change the languac 
the Admin or the user? 



the user can view the 
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1. User Profile Use Case 

1.1 Brief Description 

The User Profile use case describes how the USER would customize their working environment. User 
Profile will allow the USER to change their password, set his or her out of office, and modify their Favorite 
Locations list. 

1 .2 Use Case Actors 

Actors will use this use case to update their user profile. The following actors will interact with this use 
case: 

• ENTERPRISE ADMINISTRATOR 

• COMPANY ADMINISTRATOR 

• OFFICE ADMINISTRATOR 

• CLAIMS MANAGER 

• ADJUSTER 

• FIRST NOTICE OF LOSS ADJUSTER 

• PROCESSOR 

1.3 Pre-Conditions 

• The company must be enrolled in ARMS Web. 

• The USER must be enrolled and have an active User ID and password. 

• The USER must be logged into the ARMS Web system. 




nt-X^ar 



14.2 Basic Flow 

1 . The USER will choose to edit their User Profile. 

2. The system will display the USER'S User Profile 

3 . The USER will specify the action they would like to perform (user settings, set out of office, add a 
Favorite Location, remove a Favorite Location, edit a Favorite Location). 

4. The USER will select one of the options. 

" 5 . Based on the USER'S response, one or more of the following subflows is executed: 

• If the USER chooses to edit a Favorite Location, the Edit Favorite Location Subflow is 
executed. 

• If the USER chooses to add a Favorite Location, the Add Favorite Location Subflow is 
executed. 

• If the USER chooses to remove a Favorite Location, the Remove Favorite Location 
Subflow is executed. 

• If the USER chooses to set the Out of Office Function, the Out of Office Subflow is 
executed. 

• If the USER chooses to Change Password, the Change Password Subflow is executed. 

• If the USER chooses Confirmation Page, the Confirmation Page Subflow is executed. 

1.4.2. 1 Edit Favorite Location Subflow 

This subflow allows the USER to edit a location on their Favorite Locations List. 

1 . The USER selects the location they wish to edit from their Favorite Locations List. 

2. The USER changes the name they wish to use to identify the location. This is the name that 
will be displayed to them in their Favorite Locations List. 

3. The USER submits the information to the system. 

4. The system updates ARMSWeb to reflect the new Favorite Location. 

5. The use case ends. 

14.2.2 Add Favorite Location Subflow 

This subflow allows the USER to add a location to the Favorite Locations List. 

1 . The USER will execute Functional Specification MA-02: Find a Rental Location to search for 
the location they would like to add to their Favorite Locations List. 

2. The USER selects the location they wish to add to their Favorite Locations List. 

3. The USER enters the name they wish to use to identify the location. This is the name that 
will be displayed to them in their Favorite Locations List 

4. The USER submits the information to the system. 

5. The system updates ARMSWeb to reflect the new Favorite Location. 

6. The use case ends. 

14.2.3 Remove Favorite Location Subflow 

This subflow allows the USER to remove a location from their Favorite Locations List. 

1 . The USER selects the location they wish to remove from their Favorite Locations List. 

2 . The USER submits the information to the system. 

3 . The system updates ARMSWeb to reflect the removal of the Favorite Location. 

4. The use case ends. 

7.4.2.4 Out Of Office Subflow 

This subflow allows the USER to select when they are out of office and assigns their workload to 
another USER. 



1 . The USER will set choose to be Out of Office 

2. The USER will enter the beginning date of when they will be Out of Office. 
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The USER will choose an alternate USER to handle their work for each office the USER is 
assigned to. 

The USER submits the information to the system. 
The system validates the changes. 

The system updates ARMSWeb database to reflect the out of office status. At this time, the 
system will assign any work that exists for the USER to the chosen user(s). Any new work 
that is assigned to the USER will automatically be reassigned by the system to the chosen 
user(s). 

The use case ends. 



14.2.5 Change Password Subflow 

This subflow allows the USER to change their current password. 

1 . The USER enters the old password. 

2. The USER enters the new password of their choice. 

3 . The USER re-enters new password for verification. 

4. The USER submits the passwords to the system. 

5. The system validates the password changes. 

6. The system updates ARMSWeb to reflect the new password changes. 

7. The use case ends. 



I. 4.2.6 Confirmation Page 

This subflow allows the USER to turn on or off confirmation pages in the ARMS Web system. 

8. If Confirmation pages have been turned off, the user will turn them on. 

9. If Confirmation pages have been turned on, the user will turn them off. 

10. The USER submits the change to the system. 

I I . The system updates ARMSWeb to reflect the change. 
12. The use case ends. 



1.4.3 Alternative Flows 

1.4.3.1 Invalid Password 

At step five in the Change Password Subflow, if the current password is incorrect or if the 
confirmed password does not match the new password, the system will prompt the USER to re- 
enter the old, the new and the confirmation password. 

1.4.3 1.1 It will be*considered invalid if the new password entered was one of the USER'S last 

fi\e ARMS'Web pa^woids 
1.4.3.1.2 It will be considcicd invalid if the new passwoid is not at between s>i\ and 10 

charactcis and alphanumeric in type -Validate 1.4.3.1.1 & 1.4.3.1.2 in Sign-on 

1.4.3.2 Alternate Users not Chosen in Each Office USER is Assigned 

At step five in the Out of Office Subflow, the system will validate that a user was selected to 
handle the USER'S work in each office the USER is assigned to. If a user was not chosen for 
each office, the system will notify the USER that they must select a user to handle their work in 
each office they are assigned to. The system will then return the USER to step two of the Out of 
Office Subflow. 



1.4.3.3 Out of Office Start Date is in the Past 

At step five in the Out of Office Subflow, the system will validate that a user selected an out of 
office date that is present (today) or in the future. If the date is in the past, the system will 
generate an error and ask the USER to enter a date that is either today or in the future. The system 
will then return the USER to step two of the Out of Office Subflow. 



4.3.4 Favorite Location Name Entered is the same as an Existing Location 
When the USER submits the name for a new location, or changes the name of an existing 
location, the system will validate that the name entered is not an exact duplicate of any other name 
in that USER'S list of Favorite Locations. If the name is a duplicate, the system will prompt the 
USER to enter a different name for the location in question. The system will then return the 
USER to step one of the Edit Favorite Location Subflow. 

1.4.3.5 Cancel User Profile 

At any point during the use case up until a change has been submitted to the system, the USER 
may decide to not update their profile. 

Post-Conditions 

• If the use case was successful then either a new password has been assigned, the out of office function 
will be turned on, or the USER'S Favorite Locations will be edited. 

• If the use case was unsuccessful then the system will remain unchanged. 

Special Requirements 

None. 



Extension Points 

None. 




2. Screen Design 

A definition of the screen layouts), screen data fields, and screen functions that are used to implement the 
flows identified above. More than one screen may be used to implement support for the use case flow. 



2.1 My Profile 

This screen will allow the USER to pick which functions that they wish to change. 

^UJ^_Screer) Layout - My Profile ~ s^j^ cQr^Jf^ 




Add/Edit My Favorites List 

.Name ' " 

f 5 



r 



'< SST^ladue, , 

J-fraS Liberty < 
"2002 Lobty An 



Handling for: Yourself 



j Remove Tms Branch 



ft- 



Out of Oftirp 

©Select JeaJurq. getting 



My Settings- 
Change Passwords' 





2.1.2 My Profile 











Remove This 
Branch 


Check Box 


1 


Delete branch from 
preferred locations 
indicator 






First Day Out: 


List Box 


10 


Out of office start date 




day, year 


Off 


Radio Button 




Select feature setting 






On 


Radio Button 


1 


Select feature setting 






Off 


Radio Button 


1 


Show confirmation 
page 






On 


Radio Button 


1 


Show confirmation 
page? 







Confirm 
Password: 


Text Box 


0 


Password 


change password 


~n/a 


New Password: 


Text Box 


0 


Password 


change password 




Adjuster: 


List Box 


30 


Handler for out of 


First Name + Last 




Handling For 


Output 


15 


Handling For Adjuster 


First Name + Last 




Old Password: 


Text Box 


0 


Password 


User Paswd 


N/A. 


Address 


Output 


30 


Preferred Location 
Address 


Address Line + 
AddressLine2 




Office 


Output 


10 


Claims Office 


external organization 
abbreviated name 




Office: 


Output 


10 


Handler for out of 
office adjuster's office 


external organization 
abbreviated name 






Input 


30 


Preferred Location 


location name 


Defaults to address name 



2.1.3 Screen Function Definition 

This section includes the definitions for all functions that can be performed within the screen. 
This includes operations invoked by button clicks, specific shortcut keystrokes, or other actor 
activity. 

2.1.3.1 Process 

When clicked, the system will validate the information on the screen is correct and 
complete. If an error is found the screen will be redisplayed with a message indicating 
the error condition and highlighting the field in error. If no errors are found, the database 
will be updated with the new information. 

2. 13.2 Add A Different Office 

When clicked, the system will take the USER to MA-02-Find Rental Location Use Case. 
Here, the USER will select a new location to add to the preferred location list, and then 
return to the PR-07-User Profile Use Case. The new information will be validated and 
the database will be updated. 



/ 
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3. Application Operations 

This section will detail all the application operations that are part of this Functional Specification 
Document. 

3.1 Retrieve User Profile 

(User Id) 

Retrieve user's current profile settings. 

3.2 Update User Profile 

(User Id, Out of Office, Assigned Adjuster, Start Page) 

Update user's Out of Office status, Adjuster to handle work during out of office period, and the user's 
initial page. 

3.3 Change Password 

(Current Password, New Password, New Password Confirmation) 

Change the user's password from the current password to the new password. Validate that the current 
password is correct. 
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4. Data Fields 

4.1 Data Field Definition 

This section includes a definition of all data fields included in the functional specification. 



4.1.1 Handler for out of office user 

This is the user who will handle work for the user who is out of office. 

Data Field Type: Alpha-Numeric 

Data Field Length: 0 

Data Source: <Data Source> 



Start Page 

This is the initial page that the user will see when he k 

Data Field Type: URL 
Data Field Length: 256 
Data Source: <Data Source> 



4.1.3 Is user out of office ? 

This flag indicates that the user is out of office and no work should be assigned to them. Instead 
another user can be set up to handle for the user who is out of office. 

Data Field Type: Boolean 

Data Field Length: 1 

Data Source: <Data Source> 



4.1.4 Password 

This is the user specified password that the user will use along with the user id to log on to the 
ARMS Web System. 

Data Field Type: Password 

Data Field Length: 10 

Data Source: <Data Source> 




n 
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5. Questions and Answers 



Issue Number: 334 

Question: Is out of office assigned at the user level or at the office level? (Could you set this for 
each office you work out of?) Example: You have been created at the St. Louis Office and you 
need to travel to California to help with a disaster, does California have the rights to maintain you. 



Status: Closed - Resolved 



Resolution: 4-7-00, Issue Mtg, Defer to user review 12 

08-07-00 - Brad Reel: A user will be required to set their out of office function for all offices they 
are assigned to in order to activate the function. The function is set up using the assumption that a 
user would only be out of office if they were unreachable at all offices (vacation, training, etc.). 
Since the system can be accessed from any web connection, it is possible for a user to do work for 
any and all offices they are assigned to from anywhere. Therefore, it seems logical that a user 
would only set their out of office function if they were not available in any capacity. 



Issue Number: 335 



Question: Does a user have the field level control of the fields he can see? 



Status: Closed - Resolved 



Resolution: 4-7-00, Issue Mtg, Should be set at the Office level, the user should not be able to set 
the field that they want to see. 

4-1 1-00, Brad Reel - User does not need to have control over the fields they see. Control at the 
office (or team level, where applicable) is sufficient 



Issue Number: 336 

Question: Are we still using the "Requests to be Processed" page, (the Command Center) as an 
option for a start up page? 
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Status: Future 



Resolution: 4-7-00, Issue Mtg, Defer to future release, We are not sure that it will not be an 
option, right now it is not. 

4- 1 1-00, Brad Reel - As of right now, the "Command Center" page (Requests to be Processed) 
should not be an option for the start page, and is not even planned for the ARMS Web system. 



Issue Number: 434 



Question: 07-06-00 - Brad Reel: The ARMS Web redesign has a requirement that the system 
would allow the user to choose the page in the system they could use as their start-up page. Their 
options were: the Command Center Page, the Action Items Page, or the Create Reservation Page. 
Based on the way the system has been designed to process since that time, it does not seem to 
make sense to be able to choose anything other than the Action Items page as a user's start page. 
The profile build team suggests removing the option to allow a user to choose their start page 
from the user profile. 

07-07-00 - Brad Reel: Feedback from the technical team and the business suggests that it may 
make more sense to have Create Reservation as an option, and have it process in a different 
manner than the normal create reservation process. The main advantage of this would be First 
Notice of Loss Adjsuters. There was also consensus that if the ability to sleet your start page is 
removed in this release, it should be possible to easily add it back in the future. 
07-07-00 - Brad Reel: Upon speaking to the database and build teams, it should not be difficult to 
add the functionality back to the system in a future release. A user's start page was set up as an 
attribute of a user, and since there will still be other attributes for a user, the start page will just be 
a new attribute when it is added back. Therefore adding the ability to choose a start page in a 
future release should not be difficult. 

07-07-00 - Brad Reel: This issue is being assigned to Sean O'Donnell for review of the feasibility 
and impacts to the create reservation process if a user is allowed to enter the create res page 
without having entered the intial required fields (i.e. Claim #, Claim Type, Renter Last Name, 
etc.). This issue should be discussed for resolution at the 07-17 issues meeting and is being 
assigned to Craig Lalumandier as resolution contact until it is resolved. Upon resolution, this 
issue may need to be assigned back to Brad Reel so that the decision can be implemented into the 
user profile. 



Status: Closed - Resolved 



Resolution: 07/17/00 [Craig L.] - For the initial release, the start page will not be profiled. This 
feature would not be difficult to add in the future. 

Sean O'Donnell 07-1 1-2000 - 1 would NOT recommend allowing users to have the create 
reservation page selected as their 'Start Page' for the following reasons; 



- the reason(s) we split the reservation process into two pages to begin with still exist 1) to have 
the information to perform authorized and unauthorized matches to ensure that the reservation that 





is being created does not already exist, 2) to get the 'where needed' information to retreive a 
location & rates, 3) to get the claim type information up front so that we can build the 
authorization section of the create reservation page appropriately. 



- if we change the process to support 'FNOL' adjusters differently than the 'normal' way of 
creating a reservation, use of the application will be inconsistent. 

Please contact me if there are concerns with these statements. 




